< Network configuration (Português)

Network configuration (Português)/Ethernet (Português)

Esse artigo descreve especificidades sobre Ethernet. Configuração de rede em geral está coberto em Configuração de rede.

Status de tradução: Esse artigo é uma tradução de Network configuration/Ethernet. Data da última tradução: 2020-07-06. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Driver de dispositivo

Verificando o estado

O udev deve detectar sua interface de rede (em inglês, network interface controller ou NIC) e carregará automaticamente o módulo de kernel necessário na inicialização. Verifique pela entrada "Ethernet controller" (ou similar) no resultado do comando lspci -v. Este comando dirá qual módulo do kernel é necessário para o funcionamento do dispositivo. Por exemplo:

$ lspci -v
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0)
     ...
     Kernel driver in use: atl1
     Kernel modules: atl1

Após, veja se o driver foi carregado usando dmesg | grep nome_módulo. Exemplo:

# dmesg | grep atl1
...
atl1 0000:02:00.0: eth0 link is up 100 Mbps full duplex

Pule para a próxima sessão caso o driver tenha sido carregado com sucesso. Caso contrário, você precisará descobrir qual é o módulo necessário para o seu modelo de interface de rede em específico.

Carregando o módulo

Pesquise na internet pelo modelo/driver para o seu chipset. Algumas módulos comuns são 8139too para as placas com um chipset da Realtek, ou sis900 para placas com um chipset da SiS. Assim que descobrir qual módulo deve usar, tente carregar o módulo manualmente. Caso você esbarre com algum erro dizendo que o módulo não foi encontrado, é possível que o driver não foi incluído no kernel do Arch Linux. Tente procurar no AUR pelo nome do módulo.

Caso o udev não detecte ou não carregue o módulo de forma apropriada e automaticamente durante o boot, veja Módulo de kernel#Carregamento automático de módulos com systemd.

Dicas e truques

ifplugd para laptops

Dica: dhcpcd fornece o mesmo recurso pronto para uso.

O ifplugd é um daemon que configura automaticamente seu dispositivo Ethernet quando um cabo é conectado e desconfigura automaticamente quando desconectado. É útil para laptops com adaptadores de rede onboards, pois configurará a interface quando um cabo realmente for conectado. Outro uso é quando você deseja reiniciar as configurações de rede mas não deseja reiniciar o computador ou deseja fazer isto via linha de comando.

Por padrão, ele é configurado para funcionar para o dispositivo eth0. Estas e outras configurações como tempo de espera podem ser alterados no arquivo /etc/ifplugd/ifplugd.conf.

Solução de problemas

Trocando computadores no modem a cabo

Alguns ISP por cabo têm o modem a cabo configurado para reconhecer apenas um PC cliente, pelo endereço MAC da sua interface de rede. Uma vez que o modem a cabo aprendeu o endereço MAC do primeiro PC ou equipamento que fala com ele, ele não responderá de outro modo a outro endereço MAC. Assim, se você trocar um PC por outro (ou por um roteador), o novo PC (ou roteador) não funcionará com o modem a cabo, porque o novo PC (ou roteador) possui um endereço MAC diferente do antigo. Para reiniciar o modem a cabo para que reconheça o novo PC, você deve desligar e ligar o modem a cabo. Uma vez que o modem a cabo foi reiniciado e voltou totalmente on-line novamente (as luzes indicadoras foram instaladas), reinicie o PC recém-conectado para que ele faça uma solicitação DHCP ou faça com que ele solicite um novo lease (concessão) DHCP.

Caso este método não funcione, você deverá clonar o endereço MAC do computador original. Veja também MAC address spoofing.

Notificação de Congestionamento Explícito

Explicit Congestion Notification (ECN), Notificação de Congestionamento Explícito, pode causar problemas de tráfego com roteadores antigos/ruins . Desde o systemd 239, está habilitado para tráfego de entrada e de saída.

Para habilitar apenas ECN quando requisitado pelas conexões de entrada (padrão do kernel razoavelmente seguro):

# sysctl net.ipv4.tcp_ecn=2

Para desabilitar ECN completamente (para, por exemplo, testar se ECN estava causando problemas):

# sysctl net.ipv4.tcp_ecn=0

Veja também a documentação do kernel.

Os usuários com o Realtek 8168 8169 8101 8111(C) baseados em NIC (placas e on-board) podem notar um problema onde a NIC parece estar desativada na inicialização e não tem nenhuma luz no Link. Isso geralmente pode ser encontrado em um sistema de dual boot, onde o Windows também está instalado. Parece que o uso dos drivers oficiais do Realtek (datado de qualquer coisa após maio de 2007) no Windows é a causa. Esses drivers mais recentes desativam o recurso Wake-On-LAN desabilitando a NIC no tempo de desligamento do Windows, onde ele permanecerá desabilitado até a próxima vez que o Windows for inicializado. Você poderá notar se esse problema está afetando você se a luz do Link estiver desligada até que o Windows seja iniciado; durante o desligamento do Windows, a luz do link será desligada. A operação normal deve ser que a luz do link esteja sempre ativada enquanto o sistema estiver ligado, mesmo durante o POST. Este problema também afetará outros sistemas operacionais sem drivers mais recentes (por exemplo, Live CDs). Aqui estão algumas correções para este problema.

Habilitando a NIC diretamente no Linux

Siga Configuração de rede#Habilitando e desabilitando interfaces de rede para habilitar a interface.

Revertendo/alterando driver do Windows

Você pode reverter o driver de NIC do Windows para o fornecido pela Microsoft (se disponível), ou reverter/instalar um driver Realtek oficial pré-datado de maio de 2007 (pode estar no CD que acompanhou o hardware).

Habilitando WOL no driver do Windows

Provavelmente a melhor e mais correção é mudar essa configuração no driver do Windows. Desta forma, ele deve ser corrigido em todo o sistema e não apenas em Arch (ex.:, Live CDs, outros sistemas operacionais). No Windows, no Gerenciamento de dispositivos, encontre seu adaptador de rede Realtek e clique duas vezes nele. Na guia "Avançado", altere "Wake-on-LAN após o desligamento" para "Ativar".

No Windows XP (exemplo):

 Realize duple clique no meu computador e escolha "Propriedades"
 --> Aba "Hardware"
  --> Gerenciamento de dispositivo
    --> Adaptadores de rede
      --> "duplo clique" Realtek ...
        --> Aba "Avançada"
          --> Wake-On-Lan após o desligamento
            --> Habilitar
Nota: Novos drivers Windows do Realtek (testados com Realtek 8111/8169 LAN Driver v5.708.1030.2008, datado de 2009/01/22, disponível da GIGABYTE) podem se referir a esta opção de forma ligeiramente diferente, como Desligar Wake-On-LAN > Ativar. Parece que mudar para Desativar não tem efeito (você notará que a luz do link ainda está desligada no desligamento do Windows). Uma solução de contorno ruim é inicializar no Windows e apenas reiniciar o sistema (executar um reinício/desligamento desagradável), portanto, não dar ao driver do Windows a chance de desabilitar a LAN. A luz de link permanecerá ativada e o adaptador de LAN permanecerá acessível após o POST - isto é, até reiniciar o Windows e desligá-lo corretamente novamente.

Driver Realtek mais novo para Linux

Qualquer driver mais recente para estas placas Realtek pode ser encontrado para o Linux no site da Realtek (não testado, mas acredita que também resolve o problema).

Ativando LAN Boot ROM na BIOS/CMOS

Parece que a configuração Periféricos integrados > Onboard LAN Boot ROM > Ativado na BIOS/CMOS reativa o chip de LAN da Realtek na inicialização do sistema, apesar do driver do Windows desabilitando no desligamento do sistema operacional.

No interface with Atheros chipsets

Os usuários de alguns chips de Ethernet da Atheros estão relatando que não funciona pronto para uso (com mídia de instalação de fevereiro de 2014). A solução de trabalho para isso é instalar [link quebrado: package not found].

Broadcom BCM57780

Este chipset Broadcom às vezes não se comporta bem, a menos que você especifique a ordem dos módulos a serem carregados. Os módulos são e , o primeiro que precisa ser carregado primeiro.

Essas etapas devem ajudar se o seu computador tiver esse chipset:

  • Localize sua NIC na saída do lspci:
  • Se sua rede com fio não estiver funcionando de alguma maneira, desconecte seu cabo e, em seguida, faça o seguinte:
# modprobe -r tg3
# modprobe broadcom
# modprobe tg3
  • Conecte seu cabo de rede de volta e verifique se o módulo foi carregado com sucesso com:
# dmesg | grep tg3
  • Se esse procedimento resolveu o problema, você pode torná-lo permanente adicionando e (nesta ordem) para o vetor :
softdep tg3 pre: broadcom
Nota: Esses métodos podem funcionar para outros chipsets, tal como BCM57760.

Realtek RTL8111/8168B

O adaptador deve ser reconhecido pelo módulo . No entanto, com algumas revisões de chips, a conexão pode cair e voltar o tempo todo. A alternativa deve ser usada para uma conexão confiável neste caso. Basta adicionar à lista negra , se não for carregado automaticamente pelo udev. Veja Módulos de kernel#Carregamento automático de módulos com systemd.

Outra falha nos drivers para algumas revisões deste adaptador é um suporte fraco de IPv6. IPv6 (Português)#Desabilitar funcionalidade pode ser útil se você encontrar problemas como pendurar páginas da web e velocidades lentas.

Placa-mãe Gigabyte com Realtek 8111/8168/8411

Com placas-mãe como o Gigabyte GA-990FXA-UD3, inicializar com IOMMU desligado (o que pode ser o padrão) fará com que a interface de rede não seja confiável, muitas vezes não conseguindo se conectar, ou até conectar mas não permitindo a transferência. Isso se aplicará à NIC on-board e para qualquer outra NIC pci na máquina porque a configuração IOMMU afeta toda a interface de rede na placa. Habilitar o IOMMU e inicializar com a mídia de instalação lançará as falhas da página AMD I-10/xhci por um segundo, mas depois inicializará normalmente, resultando em uma NIC onboard totalmente funcional (mesmo com o módulo r8169).

Ao configurar o processo de inicialização para sua instalação, adicione como um parâmetro do kernel para eliminar as mensagens de erro na inicialização e restaurar a funcionalidade USB3.0.

gollark: Those do exist, yes.
gollark: I do that occasionally, insight varies.
gollark: I have entirely many books to eventually read one day maybe.
gollark: You could read arbitrary ARM SoC datasheets and rapidly lose your sanity.
gollark: That sounds "useful".
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.