OK, então isso é longo, devido à saída do comando. Não necessariamente em complexidade, já que estou mostrando apenas alguns t-shots básicos para que qualquer feedback seja apreciado.
Basicamente, eu tenho um APU1D4 razoavelmente novo em casa que eu uso para fins de monitoramento de redes e Snort IDS / IPS. Eu PXE instalado CentOS 7 para ele no 01/03 (dd / mm - estou no Reino Unido) e a partir desta data até o 09/03 (a última vez que eu joguei com ele) o sistema estava bem. De 09/03 a 13/03 eu estava muito ocupado no trabalho, então não toquei. Hoje eu tive algum tempo de inatividade e então voltei a isso. Eu estou encontrando problemas com uma das portas GigE que eu não estava presente antes.(Nota: o CentOS 7 renomeia eth0 / 1/2 para enp1s0 / enp2s0 / enp3s0.)
Estou recebendo as seguintes mensagens no terminal e em /var/log/messages em intervalos regulares:
Mar 15 10:45:50 vimto kernel: r8169 0000:03:00.0 enp3s0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Mar 15 10:45:50 vimto kernel: r8169 0000:03:00.0 enp3s0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Mar 15 10:45:50 vimto kernel: r8169 0000:03:00.0 enp3s0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Não há cronjobs para atualização automática do sistema, então devo assumir que o driver r8169 estava em uso desde quando eu construí o sistema no dia 01/03. Aqui está a saída de lspci sobre as três placas de rede:
# lspci -nn
01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
E mais adiante:
# ethtool -i enp1s0
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl_nic/rtl8168e-2.fw
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
[root@vimto ~]# ethtool -i enp2s0
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl_nic/rtl8168e-2.fw
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
[root@vimto ~]# ethtool -i enp3s0
driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
Quando se trata de t-tiro mais longe do que isso eu não estou totalmente informado sobre o que estou fazendo, mas a julgar pela saída acima da ethtool o firmware não está devidamente carregado para o NIC estou tendo o problema com.
Talvez isso também explique por que o sistema está relatando o HWADDR incorretamente, pois /etc/sysconfig/network-scripts/ifcfg-enp3s0 mostra o HWADDR correto como 00:0D:B9:XX:XX:96 (os outros dois são os mesmos, exceto o decimal dos últimos octetos, 94, 95). No entanto, a saída de ip addr está relatando:
# ip addr
...
4: enp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:10:00:80:00:10 brd ff:ff:ff:ff:ff:ff
Na verdade, o endereço MAC 00:10:00:80:00:10 retorna como "Televisão a cabo" de acordo com o seguinte: link
Os outros relatam como eu esperaria pertencer à PC Engines (fabricante da APU).
Qualquer ajuda muito apreciada.
Nota: apesar de estar no trabalho no dia 13/03, sei que houve um corte de energia em minha casa que não foi restaurado até por volta das 09:15 da manhã. No entanto, todas as três NICs estão conectadas a um roteador Mikrotik que não está tendo problemas e nem as outras duas NICs na APU. Além disso, eu tenho eles ligados em um APC SurgeArrest que eu acho que deveria fornecer alguma proteção contra essas situações.
Eu tive um problema parecido com o ThinkPad E540, a ethernet parecia não funcionar - nenhum pacote de recebimento no ifocnfig e todos os pacotes "TX" foram contabilizados como descartados.
A solução é simples - a placa de alguma forma suspende a ethernet que não tem o WakeOnLan ativado. Isso me ajudou:
ethtool -s enp3s0 wol g
ifconfig enp3s0 down
ifconfig enp3s0 up