Problemas com conexão wireless no Ubuntu 16.04 LTS - 64bits

[druidaobelix]

[...]Eu encontrei uma solução parcial que me ajuda pelo fato de eu não ter que reiniciar a máquina, mas está longe de ser o que eu realmente preciso.
Eu executei o comando sudo service network-manager restart e as redes voltaram a ser encontradas \0/
[...] e também gostaria de saber se tem como criar rotina de programação onde sempre que o wifi apresentar esse programa o código sudo service network-manager restart  seja rodado automáticamente. Isso é possivel? Seria uma gambiarra que possivelmente resolveria meu problema, ainda mais se fosse possivel implementar um laço de repetição do tipo "while" até que a conexão fosse reestabelecida.

É uma gambiarra e tanto, bastante esquisito, mas se você acha que isso ajuda enquanto não se encontra uma solução melhor, então fica a seu critério.

Vamos partir da constatação de que acionando o "service network-manager restart" a conexão é restabelecida, segundo você afirmou no seu post.

Certamente há várias formas de implentar algo nesse sentido, porém vamos nos ater a usar apenas recursos locais, imediatamente disponíveis através do bash script.

A proposta aqui, neste momento, pela mais absoluta falta de tempo, é mesmo o arroz-com-feijão, sem preocupação com um código enxuto e menos ainda elegante, desde que funcione razoavelmente bem e atenda ao que você precisa.

Sem pensar muito no assunto e sem realmente se debruçar sobre o problema, como primeira opção no momento me ocorre usar o ping, pois ele retorna valor 0 (zero) quando sucesso, então é testar essa condição.

Se for usar isso, aponte o ping contra o seu próprio roteador, usado o ip do gateway e não externamente.

Entretanto, usar o ping para essa finalidade padece de um vício de origem, uma falsa premissa, pois não é absolutamente correto dizer que quando o ping não retorna um sinal por consequência não há conexão.

Essa é uma falsa afirmativa, pois o ping pode não retornar o sinal por outras espécies de falhas, sobremodo numa conexão que em princípio não está com boa qualidade de sinal.

De toda forma, como solução gambiarra imediata talvez possa ser útil, questão de ver, testar no cenário real e ver o que acontece.

[druidaobelix]

O script pode ter o seguinte contorno:


#!/bin/sh

echo "Aguardando carregamento completo do desktop para iniciar o script..."
sleep 15

GATEWAY=$(route | grep -i default | cut -c 17-27)
echo $GATEWAY

while :
do
ping $GATEWAY -c 1 >/dev/null;
   if [ "$?" = "0" ] ;
   then
      echo "Conexao ativa-ping1"
      sleep 5;
   else

ping $GATEWAY -c 1 >/dev/null;
   if [ "$?" = "0" ] ;
   then
      echo "Conexao ativa-ping2"
      sleep 5;

   else
      echo "Restabelecendo a conexao"
      service network-manager restart
      sleep 7;
fi
   fi
done

[druidaobelix]

Explicando melhor, exatamente em razão da dificuldade conceitual de uso do ping, penso ser melhor no caso de não retorno do sinal, ao invés de desde logo acionar o comando de reconexão, melhor acionar o ping novamente, ou seja aciona duas vezes, tentando com isso minimizar a falha conceitual de uso do ping, portanto, se ocorrem duas falhas seguidas de retorno do sinal, então razoavelmente poderia imaginar que está mesmo sem conexão, daí aciona o comando de reconexão.

Apenas para efeitos de diferenciar ao testar o script, estão nomeados como ping1 e ping2, o que em tempo de execução dá uma noção melhor do que está acontecendo, é apenas essa a razão de ter 'echo' com textos diferentes.

A sugestão quanto ao uso do sleep é para controlar melhor a execução e tem duas finalidade.

O primeiro sleep, arbitrariamente assinalado como 15 segundos, deve-se ao fato que se o script for disparado antes que o desktop tenha sido completamente carregado pode ocasionar uma falha.

A questão de fundo é que o sistema faz o boot usando o systemd, o que significa executar tarefas em paralelo, então pode acontecer de que o script seja disparado antes que realmente toda a conexão de rede padrão tenha sido carregada, o que vai dar erro logo de início.

Assim, será necessário que em face do caso concreto você ajuste aí esse tempo de espera de uma forma tal que consiga trabalhar melhor.

Os sleep seguinte são porque se não fizer algo assim ele dispara o ping na velocidade do processador e acaba derrubando o próprio network-manager, vira uma maluquice, então precisa pensar em algo que reduza a velocidade de repetição disso.

Sobremodo o sleep logo após disparar o comando de reconexão precisa estar bem ajustado, o que vai depender concretamente da fluidez, ou melhor dizendo, da dificuldade concreta desse driver aí existente e em que velocidade ele consegue refazer a conexão, portanto, ajuste igualmente para um valor empírico adequado.

Atribua permissão de execução ao script:

No exemplo abaixo usei o nome de script como constatus-ping.sh [conexão (con) status ping, para diferenciar de outra abordagem, explico adiante], mas claro que pode ser qualquer um que você queira, é apenas um exemplo.

Atribuindo permissão de execução:

Código Selecionar Expandir

chmod +x constatus-ping.sh

Para execução é fazer numa janela de terminal:

Código Selecionar Expandir

sudo ./constatus-ping.sh

(possivelmente você sabe disso, mas em todo caso, note que para executar é um ponto (.) seguido de uma barra inclinada para a direita e o nome do arquivo, tudo sem espaços.)

Caso funcione bem, depois de bem testado no cenário real, pode ser colocado para iniciar automaticamente nos "Aplicativos iniciais de sessão", mas disso como fazer podemos detalhar melhor depois, vez que como há o sudo envolvido precisa autorizar a execução no sudoers.

De qualquer forma, como não tenho aqui a conexão caindo, acaba não dando para testar realmente na prática, pois tenho que forçar manualmente a desconexão, o que evidentemente não é a mesma coisa.

Bem, faça aí e vamos ver o que vai dar, entrementes é o caso de procurar uma solução real para o problema.

[druidaobelix]

Note que nesse pequeno script inicial não foram feitas nem mesmo as mais elementares verificações de consistência. Não confie muito nele.

Várias situações não estão previstas, como por exemplo, logo de início, se a obtenção do ip do gateway através do route falhar, deveria haver ali um desvio, mas não tem, então já é uma falha que deveria ser melhorada e assim por diante, verificações de consistência.

Poderia colocar um contador para que depois de um certo número de tentativas sem resposta pudesse desistir (ou não, sei lá), enfim, é facilmente perceptível que do ponto de vista puramente da lógica muito mais poderia ser adicionado.

Mas é apenas um pequeno script-gambiarra para contornar uma situação de fundo ainda incontornável.

De toda forma, querendo, você próprio pode ir introduzindo tais melhorias, se achar que é mesmo necessário.

Vá usando e testando dessa forma para ver se ajuda, porém certamente podemos fazer abordagens melhores, como por exemplo, ao invés do ping, podemos usar o nmcli para verificar a existência ou não de conexão, muito possivelmente com algumas vantagens.



                                                                                                                                                                                                                               #3600

[FaBMak]

Tópico com imagens acima do tamanho permitido. Trancado.