# Network card keeps going down

## marco.difresco

Hello,

I just purchased an ASUS XG-C100C to upgrade my computer to 10 Gbit*, but it often goes down limiting my connectivity (browser reporting no Internet connection).

Sometime it return up automatically after few seconds, but sometime I have to use 'if enp2s0 up' manually.

I am using the driver included on the kernel 4.19.97-gentoo (technically I updated to it this morning, but all the info in this post are identical with the 4.19.86-gentoo I was using since I got the card 2 days ago). I also tried with 'net-misc/AQtion' (actually it was my first choice before the kernel's drivers) both with and without lro useflag, but I had the same issues.

The following is the output from dmesg from the last hour:

```
[Sun Jan 19 12:01:47 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 12:01:52 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 12:17:15 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 12:17:21 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 12:18:22 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 12:18:28 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 12:22:26 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 12:22:30 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 12:24:27 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 12:24:32 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 12:30:35 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 12:30:41 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 12:45:22 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 12:45:28 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 12:52:09 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 12:52:14 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 13:06:32 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 13:06:42 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 13:20:22 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 13:20:28 2020] atlantic: link change old 0 new 10000

[Sun Jan 19 13:24:20 2020] atlantic: link change old 10000 new 0

[Sun Jan 19 13:24:26 2020] atlantic: link change old 0 new 10000
```

The output of 'ethtool -i enp2s05':

```
driver: atlantic

version: 2.0.3.0-kern

firmware-version: 3.1.58

expansion-rom-version: 

bus-info: 0000:02:00.0

supports-statistics: yes

supports-test: no

supports-eeprom-access: no

supports-register-dump: yes

supports-priv-flags: no
```

The output of 'ifconfig -a':

```
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 2056

        inet 192.168.0.2  netmask 255.255.255.0  broadcast 192.168.0.255

        inet6 fe80::aa5e:45ff:fe61:4bcc  prefixlen 64  scopeid 0x20<link>

        inet6 2a02:1205:34c9:6350:aa5e:45ff:fe61:4bcc  prefixlen 64  scopeid 0x0<global>

        ether a8:5e:45:61:4b:cc  txqueuelen 1000  (Ethernet)

        RX packets 751021  bytes 1030204675 (982.4 MiB)

        RX errors 0  dropped 425  overruns 0  frame 0

        TX packets 258758  bytes 32396515 (30.8 MiB)

        TX errors 1  dropped 0 overruns 0  carrier 0  collisions 0
```

For the MTU, I tested it with a series of ping tests and it seems to be the highest the ISP's modem support**, but I think to remember (I tried many different configurations in these 2 days, so I may remember wrong) that the issue was present with the default 1500.

Any suggestions on how to solve it?

Thanks in advance.

 *at the moment on my LAN I just have the switch Netgear XS508M that support 10 Gbit, but in few days I'll get a QNAP TVS-672XT NAS and coincidentally last week my ISP offered me the option to enroll to a test program to test their 10 Gbit FTTH (the new modem still have to arrive).

 ** I hoped to enable Jumbo Frames at 9000 to use with the incoming QNAP TVS-672XT, but I noticed the issue in this post so I originally thought it was the cause; is it (doesn't seems so)?

----------

## mike155

What happens if you disable link auto-negotiation in the switch and - if that doesn't help - additionally on your NIC?

Do the interface counters in your switch show errors?

----------

## marco.difresco

 *mike155 wrote:*   

> What happens if you disable link auto-negotiation in the switch and - if that doesn't help - additionally on your NIC?
> 
> Do the interface counters in your switch show errors?

 

Hi mike155,

thanks for your answer.

I tried to look around and I could not find any info if the Netgear XS508M switch I am using have any web panel to configure it, so I don't know how to do it. When I'll get home this evening I will check the ISP modem/router to see if there are any setting there. In the mean time I did change it it on the NIC via SSH (active session only, I still have to find it a way to make it permanent across reboots) and I will monitor it.

A side question: may the MTU be involved on the issue? Yesterday evening I tried to set it back to the default 1500 and so far dmesg stopped showing the link change message (but since in the meantime I had to sleep and now I am at work, I could not positively test if the connection was actually reliable).

----------

## marco.difresco

I am still out of home so I cannot test directly, but according to dmesg via SSH I am still getting a lot of:

```
[Mon Jan 20 14:53:31 2020] atlantic: link change old 10000 new 0

[Mon Jan 20 14:53:36 2020] atlantic: link change old 0 new 10000
```

I see I am not the only one with the issue: https://github.com/Aquantia/AQtion/issues/5

----------

## marco.difresco

I have been home for few hours and I have not notice any connection issue directly, but I have not surfed a lot and since dmesg still reports many link changes I presume I just got lucky that the disconnections-reconnections happened in-between page readings.

I also tried to play Lotro for few minutes and I got the latency around 98-100 ms that is way above average (I usually get between 30 to 50).

And all that with the MTU at the default 1500, so I guess it is not the cause of the problem. I checked the ISP modem for any useful log, but it just vaguely report that the LAN is fine.

Beside the link on my last post, I found other threads on various support forums about the ASUS XG-C100C disconnections, so I presume it is just a bad card in general and  therefore I will return it and get something more expensive. Any suggestion?

Thanks.

----------

## mike155

 *Quote:*   

> I also tried to play Lotro for few minutes and I got the latency around 98-100 ms 

 

Use the tools you have. Open a window and ping your router. As long as the ping roundtrip times stay below 1 ms, it's not the connection between your computer and the router that causes delays.

Have you tried to disable auto-negotiation in your switch (and on your NIC)? Does it help?

----------

## marco.difresco

 *mike155 wrote:*   

>  *Quote:*   I also tried to play Lotro for few minutes and I got the latency around 98-100 ms  
> 
> Use the tools you have. Open a window and ping your router. As long as the ping roundtrip times stay below 1 ms, it's not the connection between your computer and the router that causes delays.
> 
> Have you tried to disable auto-negotiation in your switch (and on your NIC)? Does it help?

 

Up to MTU at 2056 I can get below 1 ms:

```
#  ping -M do -s 2028 192.168.0.1

PING 192.168.0.1 (192.168.0.1) 2028(2056) bytes of data.

2036 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.959 ms

2036 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.609 ms

2036 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.750 ms

2036 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.800 ms

2036 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.365 ms

```

Anything above that I get packet loss:

```
#  ping -M do -s 2029 192.168.0.1

PING 192.168.0.1 (192.168.0.1) 2029(2057) bytes of data.

--- 192.168.0.1 ping statistics ---

5 packets transmitted, 0 received, 100% packet loss, time 163ms
```

As for auto-negotiation I disabled it on the NIC, but I don't know how to do it on the switch (Netgear XS508M) as it doesn't seems to have any web panel to configure it. Is it there any command I can use from my computer to reach it?

Thanks.

----------

## krinn

 *marco.difresco wrote:*   

> I see I am not the only one with the issue: https://github.com/Aquantia/AQtion/issues/5

 

base on this i think the issue looks clear

----------

