Desde alguns dias, estou tendo uma conexão Ethernet no meu laptop Fedora 23: a conexão de rede fica inativa por vários segundos a cada minuto.
A máquina está atualizada com o kernel mais recente (4.4.6) e pacotes.
UPDATE: O problema persiste em diferentes ambientes (diferentes cabos e switches) e independentemente do endereçamento estático ou DHCP; a conexão com um adaptador USB-Eth funcionou por uma hora ou mais, e então começou a se comportar da mesma maneira. A inicialização em um kernel antigo (4.4.3) não resolveu o problema. No entanto, ao inicializar em um Live CD com o Fedora 21, a rede com fio parece funcionar.
Alguém já passou por esse problema? Aqui está uma saída de solução de problemas (referente ao dispositivo eth enp0s25):
[root@linuxbox ~]# ip address
(...)
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether ec:b1:d7:97:9d:f2 brd ff:ff:ff:ff:ff:ff
inet 10.10.10.13/24 brd 10.10.10.255 scope global enp0s25
valid_lft forever preferred_lft forever
inet6 fe80::eeb1:d7ff:fe97:9df2/64 scope link
valid_lft forever preferred_lft forever
(...)
[root@linuxbox ~]# dmesg
(...)
[ 1403.944457] ax88179_178a 4-5:1.0 enp0s20u5: ax88179 - Link status is: 0
[ 1409.490222] e1000e: enp0s25 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[ 1409.490232] e1000e 0000:00:19.0 enp0s25: 10/100 speed: disabling TSO
[root@linuxbox ~]# ping www.google.com
PING www.google.com (172.217.16.132) 56(84) bytes of data.
64 bytes from zrh04s06-in-f4.1e100.net (172.217.16.132): icmp_seq=1 ttl=54 time=4.79 ms
64 bytes from zrh04s06-in-f4.1e100.net (172.217.16.132): icmp_seq=2 ttl=54 time=4.48 ms
64 bytes from zrh04s06-in-f4.1e100.net (172.217.16.132): icmp_seq=3 ttl=54 time=4.57 ms
64 bytes from zrh04s06-in-f4.1e100.net (172.217.16.132): icmp_seq=50 ttl=54 time=4.62 ms
64 bytes from zrh04s06-in-f4.1e100.net (172.217.16.132): icmp_seq=51 ttl=54 time=4.50 ms
64 bytes from zrh04s06-in-f4.1e100.net (172.217.16.132): icmp_seq=52 ttl=54 time=4.81 ms
64 bytes from zrh04s06-in-f4.1e100.net (172.217.16.132): icmp_seq=53 ttl=54 time=6.16 ms
(...)
^C
--- www.google.com ping statistics ---
65 packets transmitted, 11 received, 83% packet loss, time 64018ms
rtt min/avg/max/mdev = 4.486/4.803/6.164/0.469 ms
[root@linuxbox ~]# ethtool enp0s25
Settings for enp0s25:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
[root@linuxbox ~]# ethtool -S enp0s25
NIC statistics:
rx_packets: 10222
tx_packets: 1774
rx_bytes: 1146761
tx_bytes: 250438
rx_broadcast: 9287
tx_broadcast: 37
rx_multicast: 84
tx_multicast: 102
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 84
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 0
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 0
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_csum_offload_good: 9429
rx_csum_offload_errors: 0
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0
rx_dma_failed: 0
tx_dma_failed: 0
rx_hwtstamp_cleared: 0
uncorr_ecc_errors: 0
corr_ecc_errors: 0
tx_hwtstamp_timeouts: 0
[root@linuxbox ~]# uname -a
Linux linuxbox 4.4.6-300.fc23.x86_64 #1 SMP Wed Mar 16 22:10:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@linuxbox ~]# lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4)
00:1c.6 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #7 (rev d4)
00:1c.7 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #8 (rev d4)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04)
02:00.0 Network controller: Broadcom Corporation BCM43228 802.11a/b/g/n
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI Express Card Reader (rev 01)
Acho que o problema está resolvido em um ambiente. Aparentemente, alguém configurou seu endereço IP (estaticamente) igual ao meu (estático também). O conflito de endereços IP causou esse comportamento.
O problema se apresenta também em outro ambiente onde todos usam (ou devem usar) endereçamento DHCP. Vou verificar isso e atualizar essa resposta se descobrir que essa foi a causa do problema.