RTL8111/8168/8411 PCI Express Gigabit Ethernet - Disconnecting randomly

It could be that that module works only with the “normal” linux kernel, not the zen, nor the lts

So if i undestand :

r8168 work with linux (normal) kernel

r8168-dkms work with zen kernel

r8168-lts work with lts kernel

Am I right ?

And i have to try the 3 option ?

Sorry for asking so mutch, but what is the fundamental difference between thoes 3 kernel ?

1 Like

This can be answered only searching and reading on the Internet...
For an overview
https://wiki.archlinux.org/title/Kernel#Officially_supported_kernels
Eg

But I don't think those details can help much normal users for a decision.
In my opinion, the best thing is to try them all an trust your gut feeling.
There are a lot of benchmarking reviews, of course, but they require as well technical knowledge...

1 Like

Bios update?

Yours appears to be outdated.

Try setting your MTU to 9000. There are various methods for this:

https://wiki.archlinux.org/title/Network_configuration#Set_device_MTU_and_queue_length

You can also adjust your MTU through Network Manager.

Have you tried setting a static IP address?

Have you checked your LAN lease time in the router config?

Have you restarted your router?

Have you tried a better grade of network cable?

Have you checked your logs?

Do drops occur when using your wifi connection as well?

Read the troubleshooting section of Arch Wiki network configuration:

https://wiki.archlinux.org/title/Network_configuration#Realtek_RTL8111.2F8168B

3 Likes

Thank you very mutch @filo for thoes url. I undestand beter now :slight_smile:

@tbg I have never done a bios update, and its make me scary lol. Its a new pc ~1month and in the bios, the last update apear at : 25/03/2021

MTU set to 9000 i have directly no internet.
The pc are on a static ip. Local and public
The LAN lease time is 24h in the router config
Router restartted at multiple time. In lts kernel, in zen kernel.
I havent try a beter grade of network cable, but i have the exactly same (girlfriend on windows) and i have switched them but same result. And my girlfriend have no noticed i have switched the network cable and she have still internet on he's windows machine

In my error log, i got :
sudo journalctl -p 3 -xb

-- Journal begins at Sat 2021-08-28 21:49:53 CEST, ends at Sat 2021-08-28 21:51:59 CEST. --
août 28 21:49:54 local kernel: r8168  Copyright (C) 2021 Realtek NIC software team <[email protected]> 
                                 This program comes with ABSOLUTELY NO WARRANTY; for details, please see <http://www.gnu.org/licenses/>. 
                                 This is free software, and you are welcome to redistribute it under certain conditions; see <http://www.gnu.org/licenses/>. 
août 28 21:50:00 local pipewire-media-session[3438]: GetManagedObjects() failed: org.freedesktop.systemd1.NoSuchUnit

I have found a tp link ac600 work perfectly with : rtl8821au driver

I gona have a try with the troubeshooting of arch, thx very mutch for the help :wink:

I will be back!

Edit : I forget to say,
I whas testing different situation :

kernel zen with r8168-dkms whas horrible ... loosing all the time internet.
Ubuntu liveusb, out of the box work directly with the driver r8169 loaded. I have rebooted him 5x to be sure. Make the same with garuda : x5 reboot in liveGaruda whas just 2 time internet with the r8169

Actualy i have lts kernel with the r8168-lts and its the beter i have before. But still sometime i loose internet and i have to modprobe -r ; modprobe -i

This still does not rule out cabling as a cause. Windows can be more fault tolerant than Linux when it comes to borderline cables. Sometimes a cable that works fine on Windows will have issues when used on the same machine with Linux.

Cabling is the number one source of Ethernet connectivity problems. The new higher speed Ethernet cards may not function well without higher spec cabling. Cat5 cable is often insufficient for the new higher speed network cards being produced today.

This tends to indicate that the kernel and firmware Ubuntu uses might be a factor. You should find out exactly which kernel and linux-firmware Ubuntu uses in the live disk you tested.

I would also test the following kernels:

linux
linux-mainline
linux-hardened

Also test the linux-firmware-git package.

Test all with both r8168 and r8169 drivers and IPv6 enabled/disabled.

2 Likes

Ok, thx for your help @tbg :slight_smile: I gona try all this, but may be he cant take few day ... For example on lts i can ben without any problem for few hours, its realy random. But for sure i will give some news, and how i process.

1 Like

You could test this service I wrote a ways back, as sometimes a recurring ping may help to keep a connection from dropping.


Firstly, let me state it is always preferable to fix your connectivity issues by changing driver options, firmware, kernel version etc etc. Unfortunately some adapters still have disconnection issues regardless of the fixes you apply. It is a massive inconvenience if your adapter will only reconnect to the internet by rebooting. This service will hopefully help alleviate that inconvenience.

If your internet connection drops on an intermittent basis this service may be of help. The service will ping Google's servers (change servers if you wish) to determine if your connection is working. If your connection is down, then the script will automatically initiate a restart of all network components. This will hopefully revive your connection without the need to restart your computer. Sometimes a recurring ping may also help to keep a flaky connection alive.

This service should automatically restart your network connection shortly after it drops. From the time when it detects a loss of connectivity the script can be as quick as 6 seconds in re-initiating a connection. The script performs a full restart of all network components to avoid requiring a reboot. This is much quicker than the time it takes to reboot or manually restart you connection yourself. Not a fix, but it is a reasonable workaround unless gaming is your priority.

To get this auto-restart functionality you must create one service file and one script.


Network Restart Service:


#/etc/systemd/system/network-restart.service
#systemctl enable network-restart.service
#systemctl start network-restart.service
#systemctl stop network-restart.service
#systemctl disable network-restart.service
#systemctl status network-restart.service
#systemctl daemon-reload

[Unit]
Description=Network Restart Service 
WantedBy=network-pre.target 

[Service]
User=root
Type=simple
Restart=always
RestartSec=3
Restart=on-failure
StartLimitIntervalSec=0
ExecStartPre=-sleep 15
ExecStart=/usr/local/sbin/network_restart.sh

[Install]
WantedBy=network.target

Once you have created and saved the service file, enable the service:

systemctl enable network-restart.service

Network Restart Script:


With a text editor create:

/usr/local/sbin/network_restart.sh

network_restart.sh script contents:

#!/bin/bash
#/usr/local/sbin/network_restart.sh
while true; do
    ping -c 1 8.8.8.8  | grep received
    if [ $? -eq 0 ]; then > /dev/null 2>&1 &  sleep 2
else
 echo "Connection broken, restarting network connection"
    /bin/sh -c 'nmcli networking off'
      systemctl stop NetworkManager
       ip link set enp3s0 down
         modprobe -r r8169
          sleep 1
          modprobe r8169
          sleep .5
         ip link set enp3s0 up
        sleep .5
       systemctl start NetworkManager
     /bin/sh -c 'nmcli networking on'
    sleep 15
   break  
  fi
done
$(basename $0) && exit

Make the script executable:

sudo chmod +x /usr/local/sbin/network_restart.sh

The group of numbers "8.8.8.8" is Google's server address. If you would prefer to ping a server other than Google, then change the address to 1.1.1.1 or 9.9.9.9 instead.

There are lines in the script that must be modified to reflect your own networking components. In the script you must replace enp3s0 with your adapters designation if different than enp3s0. You must also insert your driver module in place of r8169 in the script if you are using a different driver. Substitute r8168 (or other) in the script if using an alternate driver.

After creating both the files reboot the computer.

After rebooting you can use the following command to test how well the connection is reestablished after it is broken:

nmcli networking off

If the service is working correctly your connection should automatically be reestablished within a handful of seconds.

I hope this service helps some people with flaky adapters that occasionally drop the connection at random times. While this is really only a workaround, hopefully it will make your adapter more usable until you find a more permanent fix.


2 Likes

Run:

journalctl -fu NetworkManager.service

Post excerpts from the log around any disconnect events.

1 Like

Wow thank's very mutch for this script and the help @tbg :wink:

I have setup your script and reboot, but the network is restarting endlessly.
I gona rm it for the moment, just the time we can find a fix.

Here is the log (pastebin because the log content so mutch line) :

And for the moment, the pc wont get back internet... I have restarted serval time but nothing :frowning:


Please post:

ping -c5 8.8.8.8
ping -c5 google.com
ping -c5 1.1.1.1
ping -c5 cloudflare.com
ping -c5 localhost
systemctl status systemd-resolved
systemctl status NetworkManager

Does network function in live environment?

Have you rebooted your router?

Are you using a VPN?


Try this:

The following command will force dhclient to refresh your IP Address:

bash -c "sudo dhclient -v -r $(hwinfo --netcard | grep "Device File" | cut -d " " -f5) && sudo dhclient -v $(hwinfo --netcard | grep "Device File" | cut -d " " -f5) && sleep 5 && sudo dhclient -v"

Also try this:

sudo rm /var/lib/NetworkManager/NetworkManager.state
sudo systemctl restart NetworkManager
sudo nmcli n on

 ╭─user@local in ~ took 4ms
 ╰─λ ping -c5 8.8.8.8
ping -c5 google.com
ping -c5 1.1.1.1
ping -c5 cloudflare.com
ping -c5 localhost
PING 8.8.8.8 (8.8.8.8) 56(84) octets de données.
64 octets de 8.8.8.8 : icmp_seq=1 ttl=119 temps=12.2 ms
64 octets de 8.8.8.8 : icmp_seq=2 ttl=119 temps=16.9 ms
64 octets de 8.8.8.8 : icmp_seq=3 ttl=119 temps=14.7 ms
64 octets de 8.8.8.8 : icmp_seq=4 ttl=119 temps=14.3 ms
64 octets de 8.8.8.8 : icmp_seq=5 ttl=119 temps=13.3 ms

--- statistiques ping 8.8.8.8 ---
5 paquets transmis, 5 reçus, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 12.242/14.312/16.925/1.566 ms
PING google.com (142.251.36.14) 56(84) octets de données.
64 octets de ams15s44-in-f14.1e100.net (142.251.36.14) : icmp_seq=1 ttl=119 temps=11.6 ms
64 octets de ams15s44-in-f14.1e100.net (142.251.36.14) : icmp_seq=2 ttl=119 temps=13.0 ms
64 octets de ams15s44-in-f14.1e100.net (142.251.36.14) : icmp_seq=3 ttl=119 temps=13.1 ms
64 octets de ams15s44-in-f14.1e100.net (142.251.36.14) : icmp_seq=4 ttl=119 temps=13.8 ms
64 octets de ams15s44-in-f14.1e100.net (142.251.36.14) : icmp_seq=5 ttl=119 temps=13.9 ms

--- statistiques ping google.com ---
5 paquets transmis, 5 reçus, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 11.592/13.079/13.858/0.819 ms
PING 1.1.1.1 (1.1.1.1) 56(84) octets de données.
64 octets de 1.1.1.1 : icmp_seq=1 ttl=59 temps=9.29 ms
64 octets de 1.1.1.1 : icmp_seq=2 ttl=59 temps=11.8 ms
64 octets de 1.1.1.1 : icmp_seq=3 ttl=59 temps=8.08 ms
64 octets de 1.1.1.1 : icmp_seq=4 ttl=59 temps=7.99 ms
64 octets de 1.1.1.1 : icmp_seq=5 ttl=59 temps=9.85 ms

--- statistiques ping 1.1.1.1 ---
5 paquets transmis, 5 reçus, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 7.990/9.408/11.830/1.402 ms
PING cloudflare.com (104.16.132.229) 56(84) octets de données.
64 octets de 104.16.132.229 (104.16.132.229) : icmp_seq=1 ttl=59 temps=8.37 ms
64 octets de 104.16.132.229 (104.16.132.229) : icmp_seq=2 ttl=59 temps=7.58 ms
64 octets de 104.16.132.229 (104.16.132.229) : icmp_seq=3 ttl=59 temps=8.18 ms
64 octets de 104.16.132.229 (104.16.132.229) : icmp_seq=4 ttl=59 temps=9.66 ms
64 octets de 104.16.132.229 (104.16.132.229) : icmp_seq=5 ttl=59 temps=7.58 ms

--- statistiques ping cloudflare.com ---
5 paquets transmis, 5 reçus, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 7.576/8.271/9.655/0.761 ms
PING localhost (127.0.0.1) 56(84) octets de données.
64 octets de localhost (127.0.0.1) : icmp_seq=1 ttl=64 temps=0.022 ms
64 octets de localhost (127.0.0.1) : icmp_seq=2 ttl=64 temps=0.025 ms
64 octets de localhost (127.0.0.1) : icmp_seq=3 ttl=64 temps=0.025 ms
64 octets de localhost (127.0.0.1) : icmp_seq=4 ttl=64 temps=0.025 ms
64 octets de localhost (127.0.0.1) : icmp_seq=5 ttl=64 temps=0.025 ms

--- statistiques ping localhost ---
5 paquets transmis, 5 reçus, 0% packet loss, time 4148ms
rtt min/avg/max/mdev = 0.022/0.024/0.025/0.001 ms
 ╭─user@local in ~ took 20s
 ╰─λ systemctl status systemd-resolved
○ systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

 ╭─user@local in ~ took 13ms
[🔴] × systemctl status NetworkManager
● NetworkManager.service - Network Manager
     Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: disabled)
    Drop-In: /usr/lib/systemd/system/NetworkManager.service.d
             └─NetworkManager-ovs.conf
     Active: active (running) since Sun 2021-08-29 22:36:46 CEST; 5min ago
       Docs: man:NetworkManager(8)
   Main PID: 515 (NetworkManager)
      Tasks: 3 (limit: 8751)
     Memory: 14.1M
        CPU: 259ms
     CGroup: /system.slice/NetworkManager.service
             └─515 /usr/bin/NetworkManager --no-daemon

août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9471] dhcp4 (enp3s0): activation: beginning transaction (timeout i>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9560] dhcp4 (enp3s0): state changed unknown -> bound, address=192.>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9568] device (enp3s0): state change: ip-config -> ip-check (reason>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9641] device (enp3s0): state change: ip-check -> secondaries (reas>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9642] device (enp3s0): state change: secondaries -> activated (rea>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9645] manager: NetworkManager state is now CONNECTED_LOCAL
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9647] manager: NetworkManager state is now CONNECTED_SITE
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9648] policy: set '@home' (enp3s0) as default for IPv4 routing and>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9655] device (enp3s0): Activation: successful, device activated.
août 29 22:37:02 local NetworkManager[515]: <info>  [1630269422.0786] manager: NetworkManager state is now CONNECTED_GLOBAL
...skipping...
● NetworkManager.service - Network Manager
     Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: disabled)
    Drop-In: /usr/lib/systemd/system/NetworkManager.service.d
             └─NetworkManager-ovs.conf
     Active: active (running) since Sun 2021-08-29 22:36:46 CEST; 5min ago
       Docs: man:NetworkManager(8)
   Main PID: 515 (NetworkManager)
      Tasks: 3 (limit: 8751)
     Memory: 14.1M
        CPU: 259ms
     CGroup: /system.slice/NetworkManager.service
             └─515 /usr/bin/NetworkManager --no-daemon

août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9471] dhcp4 (enp3s0): activation: beginning transaction (timeout i>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9560] dhcp4 (enp3s0): state changed unknown -> bound, address=192.>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9568] device (enp3s0): state change: ip-config -> ip-check (reason>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9641] device (enp3s0): state change: ip-check -> secondaries (reas>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9642] device (enp3s0): state change: secondaries -> activated (rea>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9645] manager: NetworkManager state is now CONNECTED_LOCAL
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9647] manager: NetworkManager state is now CONNECTED_SITE
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9648] policy: set '@home' (enp3s0) as default for IPv4 routing and>
août 29 22:37:00 local NetworkManager[515]: <info>  [1630269420.9655] device (enp3s0): Activation: successful, device activated.
août 29 22:37:02 local NetworkManager[515]: <info>  [1630269422.0786] manager: NetworkManager state is now CONNECTED_GLOBAL

Does network function in live environment?

I whas lucky for the installation of garuda, first boot i whas able to have internet and install him with r8169. Last day, when i whas testing ubuntu see if him get the thing. I have rebooted 5x time each other (live usb) and i whas able to have internet 2 time with garuda directly.

Have you rebooted your router?

No, but if needed i can do it. I can also try reset of the box if you want.

Are you using a VPN?

http proxy. Loaded by /etc/environement (i need to have acces at some website restricted by allowedip. I whas running without this setting before, and i whas loosing internet as actualy ^^ But for sure i can remove it if you want.

I try thoes comand now or at my next deconnexion? I can follow and reply at this thread with a another pc, and i forward the log via usb if i cant get back internet on this pc.

Realy thank you for your time and your help @tbg its realy apriciate :+1:

Next disconnection.

Disable any VPN while troubleshooting.

So your Ethernet connection is working again?

How frequent are disconnects now?

Ok, i will lauch thoes comands at the next disconnection see what apen :slight_smile:
Ok i disable now my proxy and reboot the pc to be sure.

Yes ethernet connexion is back, but i realy cant tell you about frequence because is realy random.

But lts version keep ethernet working beter thant zen kernel with r8168-dkms
On zen kernel every 2-5min i whas disconnected.

I whas disconnected, so i lauch the comand :

╭─user@local in ~ took 5ms
 ╰─λ bash -c "sudo dhclient -v -r $(hwinfo --netcard | grep "Device File" | cut -d " " -f5) && sudo dhclient -v $(hwinfo --netcard | grep "Device File" | cut -d " " -f5) && sleep 5 && sudo dhclient -v"
[sudo] Mot de passe de user :       
Internet Systems Consortium DHCP Client 4.4.2-P1
Copyright 2004-2021 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp3s0/18:c0:4d:d8:e4:2d
Sending on   LPF/enp3s0/18:c0:4d:d8:e4:2d
Sending on   Socket/fallback
Internet Systems Consortium DHCP Client 4.4.2-P1
Copyright 2004-2021 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp3s0/18:c0:4d:d8:e4:2d
Sending on   LPF/enp3s0/18:c0:4d:d8:e4:2d
Sending on   Socket/fallback
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 7
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
Internet Systems Consortium DHCP Client 4.4.2-P1
Copyright 2004-2021 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp3s0/18:c0:4d:d8:e4:2d
Sending on   LPF/enp3s0/18:c0:4d:d8:e4:2d
Sending on   Socket/fallback
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 18
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

I have unplug the ethernet cable and and replug and i have internet directly

╭─user@local in ~ 
 ╰─λ journalctl -fu NetworkManager.service
-- Journal begins at Mon 2021-08-30 10:15:27 CEST. --
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.3843] dhcp4 (enp3s0): activation: beginning transaction (timeout in 45 seconds)
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.3907] dhcp4 (enp3s0): state changed unknown -> bound, address=192.168.0.173
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.3914] device (enp3s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.3995] device (enp3s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.3997] device (enp3s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.4000] manager: NetworkManager state is now CONNECTED_LOCAL
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.4002] manager: NetworkManager state is now CONNECTED_SITE
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.4003] policy: set '@home' (enp3s0) as default for IPv4 routing and DNS
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.4013] device (enp3s0): Activation: successful, device activated.
août 30 11:54:58 local NetworkManager[525]: <info>  [1630317298.5188] manager: NetworkManager state is now CONNECTED_GLOBAL

I gona buy a another ethernet cable see what appen ..

Try this when a drop occurs:

nmcli c reload

If that restores your connection you can simply create a desktop file or an alias to renew your IP lease.

If that is not sufficient you could use:

sudo dhclient -r enp3s0 && sudo dhclient enp3s0 && sudo nmcli c reload

It is looking like this is a dhcp issue.


Also. just a little tip to make things easier for everyone trying to help you and others reading this thread. When posting logs or outputs it makes things far easier if you preface commands with LANG=C before the command. This ensures that the output is displayed in English. Most of your outputs I've been able to read adequately, but sometimes it can make things very difficult to understand when another language is output.


It would also be helpful if you could post:

cat /var/lib/dhclient/dhclient.leases

Or:

cat /var/lib/dhcpcd/dhcpcd-enp3s0.lease

Post the contents of whichever of those subdirectories contains the file with the details of your leases.

1 Like

Well ... I feal so stupid ... I have just change my ethernet and its work ...

I'm still in r8168-lts with lts kernel. Tomorow morning i will give a try with zen kernel and r8168-dkms, for now i'm so excited to have internet on this pc so i am gona play few games ! lol

Thx for all your help @tbg and for the tip with LANG=C :wink:

Really thank you for your patience @tbg, i feal bad about you. I am sorry to have spend your time.
In the future, i will alway's look at hardware fist ! I promess ! :sweat_smile:

3 Likes

No big deal, and you’re welcome.

For others always remember:

For Gigabit cards cat7 cabling is probably the minimum you want to use.

2 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.