Ubuntu 14.04 LTS nao reconhece cabo ethernet

[zekkerj]

Cabo mal montado só funciona por sorte. Não é questão de ser Ubuntu ou não.

[rmsilva]

Estou com um problema parecido, mas no meu caso o sistema deixa de reconhecer a conexão qdo coloco a máquina em suspensão. Ao ligar novamente a conexão some e eu tenho de reiniciar. Não faço ideia do que fazer pra resolver.

Isso é ser parecido? Nossa, não quero ver o que é um problema diferente.

Pois não veja.

[Tota]

Estou com um problema parecido, mas no meu caso o sistema deixa de reconhecer a conexão qdo coloco a máquina em suspensão. Ao ligar novamente a conexão some e eu tenho de reiniciar. Não faço ideia do que fazer pra resolver.

nem de longe seu problema é parecido.

pesquise na rede por ifconfig eth0 up

[Denis Ferraz]

Boa Noite a Todos!

Caro rmsilva;

Estou com um problema parecido, mas no meu caso o sistema deixa de reconhecer a conexão qdo coloco a máquina em suspensão. Ao ligar novamente a conexão some e eu tenho de reiniciar. Não faço ideia do que fazer pra resolver.

Isso é ser parecido? Nossa, não quero ver o que é um problema diferente.

Pois não veja.

Eu tive problemas com a porta ethernet de um notebook, pois, o chip de controle era o famigerado sis 191...

Fique com Deus e obrigado!

[AC]

Olá !

Estou com problema semelhante ao que foi descrito pelo Zigooo quando criou este tópico.
Para começar meu relato, vou logo antecipando que não é o cabo, nem é a placa de rede.

Ambos funcionam tanto no Rwindows que está em dual boot neste PC, quanto no Live CD da versão 10.04 que ainda tenho aqui.
A instalação transcorreu sem que fosse possível configurar a internet e, da mesma forma que narrou o Zigooo, prossegui, acreditando que conseguiria configurar depois de concluída.

Já tentei inúmeras soluções que encontrei via Google mas nenhuma delas resolveu esse problema.
Uma das tentativas que fiz e que ainda estou com o link aberto em outra aba do navegador, encontra-se neste link:

http://ubuntuforum-pt.org/index.php?topic=112966.0

Tenho um adaptador USB de WiFi da TP-Link, modelo TL-WN722 e com ele a rede conecta instantaneamente, se mantendo firme, tanto quando utilizo a instalação que fiz, quanto com boot pelos Live CDs das versões 12.04 e 14.04 que já testei.

Numa segunda máquina que tenho na mesma rede rodando Ubuntu 12.04, lembro-me que tive dificuldades para configurar a rede cabeada mas consegui resolver seguindo as dicas que encontrei na época. Com esta última versão, está bem complicado e estou apelando aqui para os experts deste forum.

Vamos aos fatos:

Tenho um roteador TP-Link TL-MR3220 na rede local, na qual, parte dos clientes adota conexão cabeada, e não utilizo servidor DHCP, portanto, todas as estaçoes (5 PCs, 3 smartphones e uma TV) possuem IP estático.

O PC em que instalei Ubuntu 14.04, já usava dual boot com Ubuntu 10.04 (Desktop 32bits) e Windows 7 (Ultimate 64 bits) e os dois sistemas funcionavam sem problemas de acesso a internet, passando a ter essa  dificuldade de acesso somente depois que instalei a versão 14.04 (Desktop 64 bits), a qual roda num disco físico dedicado para o Linux, onde fiz uma instalação limpa, ou seja, reparticionei a unidade para instalar a nova versão.

Antes que alguém solicite, aqui estão os resultados de dois comandos básicos para diagnósticos de casos assim:

lspci

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)

ifconfig

eth0   Link encap:Ethernet  HWaddr 90:e6:ba:3e:b5:c5 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:1333 errors:0 dropped:6 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:82513 (82.5 KB)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:213 errors:0 dropped:0 overruns:0 frame:0
          TX packets:213 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:15377 (15.3 KB)  TX bytes:15377 (15.3 KB)

wlan0  Link encap:Ethernet  HWaddr f4:ec:38:95:d0:9d 
          inet addr:192.168.1.201  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::f6ec:38ff:fe95:d09d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18134 errors:0 dropped:4 overruns:0 frame:0
          TX packets:14097 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8604856 (8.6 MB)  TX bytes:2400920 (2.4 MB)

Ao examinar a conexão WIRED com o Network, recebo a informação de Cable Unplugged juntamente com o endereço MAC da placa, mas sem tocar no cabo, o mesmo funciona perfeitamente no W7 e no Live CD 10.04.

Uma das diferenças que percebi quando rodo o Live CD 10.04 é que a placa de rede recebe a irq 35, enquanto que, nos outros três casos - Live CD 14.04, Live CD 12.04 e a versão 14.04 instalada no HD -  está sendo atribuida a irq 41 para a placa de rede.

Não sei se a irq 41 poderia ser a causa dessa dificuldade, e até pensei em testar a troca da irq 41 para a irq 35, mas não descobri uma forma de fazê-lo no Ubuntu 14.04.
Se alguém souber, me informe que farei o teste.

Caso seja necessário mais alguma informação sobre a configuração que tenho aqui para que alguém possa me ajudar, basta pedir que estarei atento ao tópico e responderei prontamente.

Desde já, agradeço qualquer ajuda!

PS: Não deixei claro, mas mesmo depois da instalacão do Ubuntu 14.04, assim como no boot pelo Live CD 10.04, o Win7 dessa máquina continua funcionando com a placa Realtek 8168 (on board) e mesmo cabo dito como unplugged.

[zekkerj]

AC, acesse o link http://packages.ubuntu.com/trusty/ethtool e baixe o pacote DEB para sua arquitetura.

Depois leve-o pra essa máquina e instale-o. Com ele instalado, execute os comandos abaixo e cole o resultado aqui.

sudo ethtool eth0
sudo ethtool -i eth0

Mas te adianto desde já: ter funcionado no Windows não é garantia de absolutamente nada. Nem de que o cabo está montado corretamente.
Diga-se de passagem, fica difícil ajudar quando você chega com tantas idéias pré-concebidas... a gente precisa fazer um troubleshoot completo, metódico, sempre, pra não deixar passar alguma coisa básica no problema.

[AC]

Caro zekkerj,

Estou seguindo para o link que me recomendou.
Voltarei assim que tiver concluido.

Quanto ao cabo, sou eu mesmo que monto os meus.
E pode ficar tranquilo que nesse ramo, sou experiente. rs
Valeu amigão!

[AC]

Caro zekkerj,

Eu já tinha o ethtool instalado e acho até que já havia usado os comandos que me indicou.
Pelo visto, o resultado não ajuda muito, veja só:

$ sudo ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available


$ sudo ethtool -i eth0
Cannot get driver information: No such device

O que me recomenda agora?
Independentemente do que seja, agradeço desde já.

Edição às 20:06

Depois de postar o resultado acima, constatei que a eth0 não estava mais sendo detectada pelo ifconfig.
Encontrei no link abaixo uma possível solução:

http://ubuntuforums.org/showthread.php?t=2224262

e segui as recomendações postadas por raiden2332:

sudo apt-get install linux-headers-generic build-essential dkms
wget http://ftp.de.debian.org/debian/pool/main/r/r8168/r8168-dkms_8.038.00-1_all.deb      -  (*)
sudo dpkg -i r8168*.deb
echo "blacklist r8169" | sudo tee -a /etc/modprobe.d/blacklist-r8169.conf
sudo modprobe -rfv r8169
sudo modprobe -v r8168
sudo service network-manager restart

(*) Tive apenas de corrigir de ... "_8.038.00-1_all.deb"  papa ..."_8.039.00-1_all.deb" a fim de corresponder ao arquivo disponível no servidor ftp da debian.org

e depois segui a recomendação de 2010-s onde ele sugere:

Instead of:

echo "blacklist r8169" | sudo tee -a /etc/modprobe.d/blacklist-r8169.conf

You might want to:

echo "# map the specific PCI IDs instead of blacklisting the whole r8169 module" | sudo tee -a /etc/modprobe.d/r8168-dkms.conf
echo -e "alias\tpci:v00001186d00004300sv00001186sd00004B10bc*sc*i*\tr8168" | sudo tee -a /etc/modprobe.d/r8168-dkms.conf
echo -e "alias\tpci:v000010ECd00008168sv*sd*bc*sc*i*\t\t\tr8168" | sudo tee -a /etc/modprobe.d/r8168-dkms.conf

Com isso, a situação parece ter melhorado bastante, pois agora, consultando Network a conexão Wired já não está indicada como Cable Unplugged, mas como Unmanaged e no ifconfig já está bem diferente e animador, veja só:

ifconfig

eth0     Link encap:Ethernet  HWaddr 90:e6:ba:3e:b5:c5 
          inet addr:192.168.1.101  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::92e6:baff:fe3e:b5c5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:102 errors:0 dropped:3 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15913 (15.9 KB)  TX bytes:2685 (2.6 KB)
          Interrupt:44

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:968 errors:0 dropped:0 overruns:0 frame:0
          TX packets:968 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:73608 (73.6 KB)  TX bytes:73608 (73.6 KB)

wlan0  Link encap:Ethernet  HWaddr f4:ec:38:95:d0:9d 
          inet addr:192.168.1.201  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::f6ec:38ff:fe95:d09d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18261 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15238 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:16170808 (16.1 MB)  TX bytes:1812633 (1.8 MB)

E também, os resuultados dos comandos sugeridos por você mudaram, passando a ser assim:

sudo ethtool eth0

Settings for eth0:
   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: Symmetric Receive-only
   Advertised auto-negotiation: Yes
   Speed: 10Mb/s
   Duplex: Full
   Port: Twisted Pair
   PHYAD: 0
   Transceiver: internal
   Auto-negotiation: on
   MDI-X: Unknown
   Supports Wake-on: pumbg
   Wake-on: g
   Current message level: 0x00000033 (51)
                drv probe ifdown ifup
   Link detected: yes

sudo ethtool -i eth0
driver: r8168
version: 8.039.00-NAPI
firmware-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

O que me diz agora?
Acredito que estejamos chegando quase lá!

[AC]

Caro zekkerj,

Como suspeitei, nós estávamos mesmo muito próximos da solução e finalmente o problema está resolvido.

Depois do que relatei ao editar o post anterior, constatei que mantendo habilitada apenas a alternativa Networking eu já tinha a opção Connection Information ativa.
Clicando nesta alternativa para obter informações sobre a conexão, recebia uma mensagem dizendo:

No valid active connections found.

Pesquisando essa mensagem no Google, cheguei ao link abaixo:

http://www.omgdba.com/fixed-no-valid-active-connections-found-on-ubuntu-14-04-lts/

Segui a sugestão para editar o arquivo etc/NetworkManager/NetworkManager.conf fazendo a seguinte alteração na seção [ifupdown]:

de:
[ifupdown]
managed=false

para:
[ifupdown]
managed=true

Feito isso, ao reiniciar a rede com sudo service network-manager restart a conexão ocorreu imediatamente.

Espero que os colegas que estejam enfrentando este problema com Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller, possam se beneficiar dessa solução.

Mais uma vez, agradeço por sua pronta ajuda.

[zekkerj]

Não me agrada nem um pouco solução que usa driver alternativo pra placa que funciona com o driver padrão. Eu acho que vale investigar um pouco mais pra ver se vc consegue voltar ao driver padrão e manter tudo funcionando.

[AC]

Não me agrada nem um pouco solução que usa driver alternativo pra placa que funciona com o driver padrão. Eu acho que vale investigar um pouco mais pra ver se vc consegue voltar ao driver padrão e manter tudo funcionando.

Eu achava que o drive padrão no Ubuntu 14.04.1 era o r8169, porém, posso estar enganado.
Sobre esse drive, encontrei o Bug 1275161 citando problemas e recomendando substituir pelo r8168, veja aqui:

https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-3.0.0/+bug/839393

Foi por esse motivo que usei o r8168 liberado e atualizado pela Realtek em 18/09/2014, veja:

http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=5&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#2

Pelo seu comentário, concluo que estou equivocado, e gostaria que me orientasse, se for possível, claro, como voltar ao drive padrão e qual seria esse drive.

Agradeço sua ajuda.

[zekkerj]

O principal problema com driver proprietário é que vc perde ele na atualização do kernel. Me parece que o driver que vc está usando é baseado no DKMS, que não tem esse problema, o que também aponta que não é o driver do fabricante, e sim algum driver já adaptado pela comunidade.

Veja se você está com a versão mais nova do kernel, de repente ela já corrige esse problema.

[AC]

O principal problema com driver proprietário é que vc perde ele na atualização do kernel. Me parece que o driver que vc está usando é baseado no DKMS, que não tem esse problema, o que também aponta que não é o driver do fabricante, e sim algum driver já adaptado pela comunidade.

Veja se você está com a versão mais nova do kernel, de repente ela já corrige esse problema.

O Software Updater informa que o sistema está atualizado e o Kernel que estou usando é:

uname -r
3.13.0-37-generic

O driver que tenho em uso, apesar de ter baixado do servidor ftp.debian.org, é o que está disponível no site do fabricante da minha placa de rede (on board).

Poderia me dizer se para confirmar qual o driver padrão usado nesta versão posso iniciar o computador pelo Live CD que baixei e verificar o drive com lsmod?

É que tenho a impressão de que o Kernel já foi atualizado depois que fiz a instalação, mas isso posso verificar com o boot pelo CD.

Obrigado por sua paciência e interesse em ajudar.

Edição para confirmar que:

Kernel do Live CD: 3.13.0-32
Driver da placa de rede do Live CD: r8169

[zekkerj]

Então, o driver que vc está usando é baseado em DKMS. Esse modelo consegue passar de um kernel pro outro, pq o sistema o recompila (ou remonta, sei lá) sempre que o kernel é atualizado. Foi instalado a partir de um pacote deb, isso explica pq ele "sobrevive" à atualização do kernel. Isso tudo é característica dos drivers desenvolvidos pela comunidade.

Sendo um driver instalado por pacote deb, é muito provável que baste remover esse pacote pra voltar ao driver nativo.

O fato da versão desse driver ser a mesma que a do fabricante é uma boa indicação, mas não significa que seja o mesmo driver, pois a comunidade pode ter ajustado o código para a versão corrente do kernel. E sendo o driver um código complexo, que é parte de um outro código ainda mais complexo (o kernel), às vezes uma linha alterada faz toda a diferença.

Aliás, minha restrição contra os códigos de fabricante está justamente aí: dificilmente o fabricante faz um driver e mantém o seu código sincronizado com o kernel corrente. Cansei de ver gente que tentou trazer driver de fabricante, e na hora de compilar descobriu que o código era pro kernel 2.6, ou mais antigo.

[AC]

Olá, zekkerj!

Valeu pelas importantes dicas!
Esse driver que estou usando, segundo consta no site da Realtek, é "for kernel 3.x and 2.6.x and 2.4.x".
E se as atualizações futuras do kernel irão mantê-lo, está ótimo!
Obrigado por seus esclarecimentos!