estive verificando este tópico aqui, mais sem sucesso.
https://community.ubnt.com/t5/Instal...d/td-p/1203135
Desabilita sua criptografia e verifique se o erro permanece.
Enviado via GT-I9515L usando UnderLinux App
Meu problema em tentar isso e ter que deixar todos os clientes de determinado setor a ser testado, deixar eles off line.
To testando o comando que encontrei nesse forum do link mais acima, agora vou monitorar se o problema persiste
O jeito que lembro é com criptografia mesmo, ou mudar pra WPA2-AES ou deixar sem. Mas também mesmo com WPA2-AES o chipset manda o aviso (Não é exclusivo do AirOS, é nativo dos chipsets atheros).
A mensagem pra mim na verdade é sinal de troca de chaves ou perda de pacotes de sincronia, de muitos clientes ao mesmo tempo, parece que as vezes o problema quase some quando diminui potência e cia porque aí sobra mais qualidade de alimentação pro chipset processar os pacotes, e as vezes é questão de botar ack-timeout fixo e bem mais alto que o necessário em todos, pro rádio não ter que processar até essa decisão. Se tivesse config. pra escolher o timeout das chaves seria só colocar um valor diferente em cada cliente (Um 10,5h, outro 3h, outro 4,4h, e assim vai), mas sem essa config. no AirOS o jeito é tentar diminuir processamento no chipset de RF, ack-timeout fixo e alto acho que é um dos mais simples, canal fixo, largura de canal fixa, data rate fixo, potência fixa, enfim, fixando tudo já diminui necessidade de processamento, mas especialmente ack-timeout porque os pacotes de sincronia da conexão NÃO SÃO feitos no data rate que você seleciona, sempre são no data rate de preambulo (1, 2 ou 6Mbps) que já tem sensibilidade ótima, mas... que tem throughput baixo, aí quando muito cliente chega com tanto pacote de sincronia ao mesmo tempo o AP não consegue responder.
(E nos firmwares mais novos, mudar o data rate module nos clientes que isso existir, ou no AP, eventualmente dá uma atrasada nos pacotes de sincronia pra evitar muitos chegando ou dando timeout ao mesmo tempo)
A troca de chave ocorre naturalmente sem cair conexão, todo dia, está caindo a conexão por algum problema na sincronia no AP, curiosamente isso só acontece quando tem muito cliente simultâneo, ou com tem distância meio longa envolvida.
@rubem, estou com WPA2-AES, as quedas ocorrem de no intervalo de 1 hora
Sei. O "key renewall interval" é isso aí, o tempo pra trocar as chaves (A troca é criptografada, mesmo com a mesma senha as chaves são trocadas) no default geralmente é justo 3600 segundos.
Seria essas config's:
O problema é: Cadê essa opção nos AirOS? Por isso eu digo que é um setup capado, sem opções avançadas, típico dos produtos de ex-funcionários da Apple (Tipo o dono da UBNT) e da própria Apple.
Não podia cair a conexão quando troca as chaves, mas se tem muito rádio fazendo a requisição ao mesmo tempo, pode cair, por isso setup AVANÇADOS tem a opção de alterar isso. SE falta essa opção o jeito é tentar gambiarra tipo ack-timeout maior nas estações e na base, mudar encriptação, mudar data rate, enfim, tentar aliviar o processamento do chipset pra que ele não perca tanto pacote na hora de negociar a troca de chaves a cada 3600s (60min, ou 1h).
@rubem , é a primeira vez que vejo uma explicação convincente sobre este problema de desconexão.
Achar provável motivo é fácil. Quero ver achar solução! :-)
Firmware bem esmiuçado (RouterOS, Open-WRT) tem mais opções pra contornar o problema, nem sempre resolve, mas se aumentar isso pra 86 mil segundos (O limite, geralmente) dá uma queda por dia, já fica aceitável.
diminui a potência, mais o erro persiste.
Atualmente minha senha da criptografia é 41 caracteres, estava pensando em diminuir para 12. Será que mudaria em algo?
Bom dia amigo, o DFS esta habilitado? Se sim favor desative e faça os testes...
ja passei por isto e unica coisa que resolveu foi diminuir a chave
Acabei de mexer num roteador Intelbras, e na hora de configurar criptografia vi na aba de segurança o "Grou Key Renewall" por default em 86400 segundos (24h, ou 1d) e lembrei desse post! :-)
Uma coisa que lembrei é que uns chipsets de RF tem sisteminhas de detecção de ataque por força-bruta, por isso troca as chaves meio rápido, e acho que isso não é desabilitável via software (Tipo a detecção de ethernet half ou full, nativamente é "auto" e não tem como alterar nalguns chipsets). Talvez então a UBNT não tenha a opção (No chipset de RF que usa, deve ser AR9280 nesse Rocket M5) de alterar isso, e sempre sempre fixo em 1h (3600s) com qualquer firmware, e por isso a UBNT não toca oficialmente no assunto (Não teria como resolver via software uma característica do hardware).
Mas... Mikrotik tem lá a opção, na config de criptografia é só dar um group-key-update=1d e pronto, só troca chaves 1x por dia. E... acho que tem MK usando os mesmos chipset de RF que UBNT, nunca reparei.
Talvez no prompt de comando do AirOS da UBNT dê pra mexer nisso, ou via SSH/Telnet, não tenho nenhum Rocket aqui pra testar, se tem (Pelo help ou ?, se tiverem) algo tipo
ath0 setkeygrouptimeout=86400
@Bruno, então se eu diminuir, consigo resolver essas desconexões?
quantos caracteres usa em sua chave?
8
Lá no forum da Ubiquiti tem alguma coisa sim. Pena que não deu prosseguimento para a solução.
Mas o Jamie deu uma orientação muito semelhante ao que o @rubem citou.
https://forum-pt.ubnt.com/discussion...iando-estacoes
Última edição por 1929; 22-03-2017 às 00:41.
Só sei que ta complicado essas desconexões para meus clientes, estou pensando em diminuir a quantidade de caracteres da senha de rede, e ver se o problema persiste.