Ubuntu perdendo sistematicamente a conexão com fio

2

Estou trabalhando em 11,10 há poucos dias, tudo estava funcionando perfeitamente até hoje. Ubuntu atualizado (alguns certificados foram atualizações, tanto quanto me lembro) e a partir deste momento, a rede com fio pára de funcionar de forma aleatória e sistematicamente. (Todos os outros pcs / macs funcionam bem)

From 192.168.0.9 icmp_seq=25 Destination Host Unreachable
From 192.168.0.9 icmp_seq=26 Destination Host Unreachable
From 192.168.0.9 icmp_seq=27 Destination Host Unreachable
From 192.168.0.9 icmp_seq=28 Destination Host Unreachable
From 192.168.0.9 icmp_seq=29 Destination Host Unreachable
From 192.168.0.9 icmp_seq=30 Destination Host Unreachable
From 192.168.0.9 icmp_seq=31 Destination Host Unreachable
64 bytes from 192.168.0.1: icmp_req=32 ttl=64 time=1003 ms
64 bytes from 192.168.0.1: icmp_req=33 ttl=64 time=0.496 ms
64 bytes from 192.168.0.1: icmp_req=34 ttl=64 time=0.576 ms
64 bytes from 192.168.0.1: icmp_req=35 ttl=64 time=0.522 ms
64 bytes from 192.168.0.1: icmp_req=36 ttl=64 time=0.624 ms
64 bytes from 192.168.0.1: icmp_req=37 ttl=64 time=0.625 ms
64 bytes from 192.168.0.1: icmp_req=38 ttl=64 time=0.555 ms

Funcionará por 20 segundos e depois parará de funcionar por 10 a 30 segundos e assim por diante. Eu tentei configurar meu roteador para fornecer IPs estáticos, isso não ajuda. NADA foi alterado desde ontem, ao lado da atualização do pacote ...

Aqui estão outras configurações que podem ser úteis:

baka@baka-PC:~/Private/projects/wduk$ lspci -nnk | grep -iA2 net
06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06)
Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards [1043:8432]
Kernel driver in use: r8169

baka@baka-PC:~/Private/projects/wduk$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr **Removed MAC address** 
      inet addr:192.168.0.9  Bcast:192.168.0.255  Mask:255.255.255.0
      inet6 addr: fe80::ca60:ff:fe0a:85b2/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:6400 errors:0 dropped:6400 overruns:0 frame:6400
      TX packets:7085 errors:0 dropped:107 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:4191983 (4.1 MB)  TX bytes:886881 (886.8 KB)
      Interrupt:72 Base address:0x2000 

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:16436  Metric:1
      RX packets:2522 errors:0 dropped:0 overruns:0 frame:0
      TX packets:2522 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:1070130 (1.0 MB)  TX bytes:1070130 (1.0 MB)

baka@baka-PC:~/Private/projects/wduk$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 8.8.8.8

obrigado pela ajuda

    
por Lukasz Baczynski 30.03.2012 / 13:03

3 respostas

2

A instalação do driver r8168 corrigirá o problema.

    
por Tim 30.03.2012 / 18:06
0

Eu tive um problema semelhante (sem fio intermitente) e a instalação dos drivers corretos aliviaram o problema. MAS, uma nota sobre drivers. Para mim, os drivers oferecidos pelo OEM (ASUS) não eram os mais atualizados para o Kernel no 11.10. Eu tive que ir ao site do fabricante do chip wifi (Realtek) para obter os drivers corretos. Grande dor de cabeça para descobrir isso, especialmente para usuários inexperientes do Linux. Para esses drivers, clique aqui: link

Além disso, mexi com a configuração MTU nas opções sem fio. Mesmo antes de instalar os novos drivers que ajudaram a aliviar o problema (suponho que estava perdendo pacotes ou algo do tipo). Isso também pode ter contribuído para a correção.

Melhor da sorte.

    
por Nate 01.04.2012 / 13:08
0

Eu não sou um "geek", mas isso também aconteceu comigo e eu tive que iniciar a partir de outros programas para voltar à rede, o que você também fez eu presumo;

Isso é o que funcionou para mim- Em 'Editar Conexões'- Sob as conexões na parte superior da tela, vá para "Nome da Conexão" - isso deve ser automático (eth0) -MTU deve ser automático-IPv4 configurações devem Método: Automático (DHCP). CERTIFIQUE-SE de que ambos (Require IP4addressing para esta conexão para completar), E (disponível para todos os usuários), estão marcados na pequena caixa, E IP v 6 configurações-Método: Ignorar e marque a caixa disponível para todos os usuários. p>

             This worked for me, hope it works for you also
    
por gypd 17.04.2013 / 07:21