Hi all,

 

I'm posting here after trawling through endless results relating to this particular chipset and not finding any solutions to my current problem.

 

I've just built a new server, centered around a Gigabyte B760M DS3H DDR4 board. This board contains the Realtek RTL-8125 controller. Upon moving my installed USB from the old machine to this new one, everything has worked without issue, except for networking. I've tried the usual (cleared the network.cfg file, rebooted router, rebooted the machine a few times) to no avail.

Issue I'm having is that while the NIC will connect to my network and I get an IP address etc., working with the web UI is taking a very long time, but with bouts of working absolutely fine (snappy, quick etc.), but every so often it hangs before continuing. This is mirrored when accessing the server over SSH, the connection will hang on input and will either timeout or catch up.

 

When accessing the machine directly, I have no such slowdowns and can navigate via the CLI without issue. However, I am unable to ping anything despite DNS being correctly setup. This means the server seems to only work locally with specific IP addresses and periodically drops from the network before recovering and being usable again.

 

I was able to get the RTL-8125 plugin installed from CA (and can see with lspci -v that the correct driver is in use after reboot) by using a USB C gigabit controller I had handy, however this uses the RTL-8153 chipset and therefore different drivers. This does not appear to have had any substantial change versus the bundled 8169 driver that was in use previously.

 

I'm attaching diagnostics in the hope that someone more experienced than I can help me to pinpoint the issue.

 

Thanks,

bertha-diagnostics-20240816-1331.zip

That NIC should work perfectly fine with the stock driver, try booting with a different flash drive using a stock install, no key needed, and see if the GUI works OK.

3 hours ago, JorgeB said:

That NIC should work perfectly fine with the stock driver, try booting with a different flash drive using a stock install, no key needed, and see if the GUI works OK.

Thanks for the reply, Jorge.

 

I wasn't going to come back here, but I had to come back hat in hand.

 

So, I tried a new flash drive, used the USB creator with 6.12.8 to avoid any unfair advantages of newer versions. I setup the same static IP assignment in the tool and booted it with exactly the same behaviour. However, I then did something I suppose I should have earlier today and changed the static IP assignment by 1 digit. This solved my problems instantly, so I knew that it was nothing to do with my configuration and simply something to do with that IP address.

I booted my usual flash drive and verified the same by changing the IP assignment, and then used

 

arping -I br0 10.0.0.100

 

getting a reply from my old motherboard's MAC address. Huh.

Turns out that despite not having any DHCP reservations setup for that IP, I still had the ghost of the old board hanging around. I rebooted all of my networking gear and flushed every cache I could, all to no avail. I even factory restored my router and reinstalled a known good backup of it.

 

Turns out that I have forgotten about the MAC/IP binding I added in the router a few years back after I realised my router didn't care much for DHCP reservations, but seemed to honour binding (can't be that good though since the new machine was still fighting its way through).

So, for anyone with a TP-Link router experiencing what appears to initially be an IP conflict, check your binding settings in your router config - mine's under "Security", nowhere near any of the DHCP stuff.

 

tl;dr - I forgot I bound the IP address for the server to its MAC. I've updated the MAC binding and all is well in the world.

Thanks again and cheers for reading the story.