WiFi instável no Vaio VPCEG36FX

Iniciado por simba202020, 21 de Dezembro de 2020, 14:55

tópico anterior - próximo tópico

simba202020

Olá, uso o Ubuntu 20.10 num Sony Vaio VPCEG36FX. Desde que fiz a instalação, já tive vários episódios de instabilidade ou intermitência no WiFi. Podem me ajudar na configuração, por gentileza? Como vi em outros tópicos, colei as saídas dos seguintes comandos abaixo:

sudo lshw -C network
ifconfig -a
iwconfig
nmcli dev list
rfkill list wifi

Muito obrigado.
João Paulo


sudo lshw -C network
[sudo] senha para jpnucci:
  *-network                 
       descrição: Interface sem fio
       produto: Centrino Wireless-N 1000 [Condor Peak]
       fabricante: Intel Corporation
       ID físico: 0
       informações do barramento: pci@0000:02:00.0
       nome lógico: wlp2s0
       versão: 00
       serial: 74:e5:0b:9d:4e:1a
       largura: 64 bits
       clock: 33MHz
       capacidades: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuração: broadcast=yes driver=iwlwifi driverversion=5.8.0-33-generic firmware=39.31.5.1 build 35138 1000-5.uc ip=192.168.15.11 latency=0 link=yes multicast=yes wireless=IEEE 802.11
       recursos: irq:30 memória:d2500000-d2501fff
  *-network
       descrição: Ethernet interface
       produto: AR8151 v2.0 Gigabit Ethernet
       fabricante: Qualcomm Atheros
       ID físico: 0
       informações do barramento: pci@0000:09:00.0
       nome lógico: enp9s0
       versão: c0
       serial: 78:84:3c:b4:cd:56
       capacidade: 1Gbit/s
       largura: 64 bits
       clock: 33MHz
       capacidades: pm msi pciexpress vpd bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuração: autonegotiation=on broadcast=yes driver=atl1c driverversion=5.8.0-33-generic latency=0 link=no multicast=yes port=twisted pair
       recursos: irq:33 memória:d1400000-d143ffff porta de E/S:2000(tamanho=128)



ifconfig -a
enp9s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 78:84:3c:b4:cd:56  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Loopback Local)
        RX packets 860  bytes 89175 (89.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 860  bytes 89175 (89.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.15.11  netmask 255.255.255.0  broadcast 192.168.15.255
        inet6 fe80::fccc:4ff8:d8d2:4b75  prefixlen 64  scopeid 0x20<link>
        ether 74:e5:0b:9d:4e:1a  txqueuelen 1000  (Ethernet)
        RX packets 16977  bytes 10524639 (10.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13445  bytes 3607165 (3.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



iwconfig
lo        no wireless extensions.

enp9s0    no wireless extensions.

wlp2s0    IEEE 802.11  ESSID:"SetteNucci" 
          Mode:Managed  Frequency:2.452 GHz  Access Point: 88:6A:E3:C7:5E:94   
          Bit Rate=65 Mb/s   Tx-Power=14 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=70/70  Signal level=-32 dBm 
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:1  Invalid misc:13   Missed beacon:0



nmcli dev list
Erro: argumento "list" não compreendido. Tente passar --help.


rfkill list wifi
0: sony-wifi: Wireless LAN
   Soft blocked: no
   Hard blocked: no
1: phy0: Wireless LAN
   Soft blocked: no
   Hard blocked: no



zekkerj

Sua conexão parece muito estável, na saída dos comandos passados.

Quais são os sintomas que você percebe que te fizeram concluir que o problema é no seu notebook?

Vi que o endereço IP de sua rede Wi-Fi é da faixa 192.168.15.0/24. Por acaso você é cliente da Vivo ou da finada GVT?
Pesquise antes de perguntar, sua dúvida pode já ter sido respondida.
Não respondo dúvidas por MP, coloque sua dúvida no fórum onde ela pode ser pesquisada pelos seus colegas!
Não venha ao fórum apenas para perguntar. Se você sabe a resposta de um problema, porque não ajudar seu colega? ;D

simba202020

Sou cliente da finada GVT, que virou Vivo. O notebook da minha mulher, que roda windows, não dá problemas desse tipo.
No momento está funcionando normalmente, mas tem ocasiões, como hoje de manhã, que as páginas simplesmente não carregam.
Estive em outra rede, também da vivo, no fim de semana, e ocorreu o mesmo.
Obrigado por enquanto.

zekkerj

Quanto tempo duram as interruções? Segundos, minutos?

Gostaria que, se possível, fizesse um teste, durante uma das interrupções. Abra uma janela de comandos, aguarde o momento em que a internet falhar, e execute os comandos abaixo:

ping -c 10 8.8.8.8
ping -c 10 www.google.com


Cole o resultado aqui pra gente analisar.
Pesquise antes de perguntar, sua dúvida pode já ter sido respondida.
Não respondo dúvidas por MP, coloque sua dúvida no fórum onde ela pode ser pesquisada pelos seus colegas!
Não venha ao fórum apenas para perguntar. Se você sabe a resposta de um problema, porque não ajudar seu colega? ;D

simba202020

Aconteceu outra vez. Seguem os resultados:

ping -c 10 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=6 ttl=118 time=10297 ms

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 1 received, 90% packet loss, time 9216ms
rtt min/avg/max/mdev = 10296.804/10296.804/10296.804/0.000 ms, pipe 5


ping -c 10 www.google.com
PING www.google.com (216.58.202.164) 56(84) bytes of data.
64 bytes from 216.58.202.164: icmp_seq=2 ttl=118 time=5532 ms
64 bytes from gru06s30-in-f164.1e100.net (216.58.202.164): icmp_seq=3 ttl=118 time=4509 ms
64 bytes from gru06s30-in-f4.1e100.net (216.58.202.164): icmp_seq=4 ttl=118 time=3485 ms
64 bytes from gru06s30-in-f4.1e100.net (216.58.202.164): icmp_seq=5 ttl=118 time=2517 ms
64 bytes from gru06s30-in-f4.1e100.net (216.58.202.164): icmp_seq=6 ttl=118 time=1556 ms
64 bytes from gru06s30-in-f4.1e100.net (216.58.202.164): icmp_seq=7 ttl=118 time=3941 ms

--- www.google.com ping statistics ---
10 packets transmitted, 6 received, 40% packet loss, time 25320ms
rtt min/avg/max/mdev = 1555.538/3589.816/5532.449/1293.731 ms, pipe 6



zekkerj

OK.
Não é como eu esperava, não é um problema de DNS. Também não é um problema de perda total de comunicação, você ainda consegue receber parte do tráfego, apesar de ter muitas perdas (que afetam decisivamente sua navegação).

Infelizmente ainda preciso de informações pra formar uma hipótese da origem do problema. Se possível, quando acontecer novamente, execute os testes abaixo:

ping -c 10 192.168.15.1
iwconfig


Cole os resultados aqui.
Pesquise antes de perguntar, sua dúvida pode já ter sido respondida.
Não respondo dúvidas por MP, coloque sua dúvida no fórum onde ela pode ser pesquisada pelos seus colegas!
Não venha ao fórum apenas para perguntar. Se você sabe a resposta de um problema, porque não ajudar seu colega? ;D

simba202020

Aconteceu de novo. Seguem os resultados. Obrigado mais uma vez pela atenção.

ping -c 10 192.168.15.1
PING 192.168.15.1 (192.168.15.1) 56(84) bytes of data.
64 bytes from 192.168.15.1: icmp_seq=2 ttl=64 time=6227 ms
64 bytes from 192.168.15.1: icmp_seq=6 ttl=64 time=5204 ms
64 bytes from 192.168.15.1: icmp_seq=7 ttl=64 time=4180 ms
64 bytes from 192.168.15.1: icmp_seq=2 ttl=64 time=9300 ms (DUP!)
64 bytes from 192.168.15.1: icmp_seq=9 ttl=64 time=6478 ms
64 bytes from 192.168.15.1: icmp_seq=10 ttl=64 time=5463 ms

--- 192.168.15.1 ping statistics ---
10 packets transmitted, 5 received, +1 duplicates, 50% packet loss, time 9187ms
rtt min/avg/max/mdev = 4180.461/6142.287/9300.352/1595.990 ms, pipe 9

iwconfig
lo        no wireless extensions.

enp9s0    no wireless extensions.

wlp2s0    IEEE 802.11  ESSID:"SetteNucci" 
          Mode:Managed  Frequency:2.452 GHz  Access Point: 88:6A:E3:C7:5E:94   
          Bit Rate=7.2 Mb/s   Tx-Power=14 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=70/70  Signal level=-15 dBm 
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:275  Invalid misc:3   Missed beacon:0




zekkerj

OK... esse teste confirmou que o problema é no primeiro hop, ainda dentro da rede local.

Comparando a saída do "iwconfig" normal com a da hora do problema, vejo que há uma queda significativa na qualidade do sinal:

Citação de: Anteswlp2s0    IEEE 802.11  ESSID:"SetteNucci"
          Mode:Managed  Frequency:2.452 GHz  Access Point: 88:6A:E3:C7:5E:94   
          Bit Rate=65 Mb/s   Tx-Power=14 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=70/70  Signal level=-32 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:1  Invalid misc:13   Missed beacon:0

Citação de: Depoiswlp2s0    IEEE 802.11  ESSID:"SetteNucci"
          Mode:Managed  Frequency:2.452 GHz  Access Point: 88:6A:E3:C7:5E:94   
          Bit Rate=7.2 Mb/s   Tx-Power=14 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on
          Link Quality=70/70  Signal level=-15 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:275  Invalid misc:3   Missed beacon:0

Pra mim está bem claro que há um problema ambiental com o qual seu adaptador wireless não está sabendo lidar. Nós temos duas alternativas óbvias, que são resolver o problema ambiental, ou melhorar o comportamento do adaptador frente ao problema. O chato é que nenhuma das duas alternativas é fácil de implementar.

Uma sugestão que te deixo é usar o Ubuntu 20.04 LTS, em vez do 20.10. Embora seja uma versão mais antiga, é uma versão LTS. Os desenvolvedores costumam ser mais "conservadores" nas atualizações disponibilizadas paras as versões LTS, o que implica em menos problemas de compatibilidade. Se isso não resolver, podemos experimentar atualizações de driver, ou talvez firmwares alternativos.
Pesquise antes de perguntar, sua dúvida pode já ter sido respondida.
Não respondo dúvidas por MP, coloque sua dúvida no fórum onde ela pode ser pesquisada pelos seus colegas!
Não venha ao fórum apenas para perguntar. Se você sabe a resposta de um problema, porque não ajudar seu colega? ;D

simba202020

Boa, vou tentar voltar pro 20.04. Obrigado pela atenção, um abraço.