4 Anexo(s)
Erro ROCKETs M5 "group key handshake completed"
Amigos estou com erro na minha rede, principalmente rocket m5, apresenta essa mensagem "group key handshake completed", segue as imagens com o erro e as configurações de alguns, se algum dos membros desse grupo tiver passado por esse problema e solucionado, porfavor peço ajuda.
Anexo 66401Anexo 66402Anexo 66403Anexo 66404
Re: Erro ROCKETs M5 "group key handshake completed"
estive verificando este tópico aqui, mais sem sucesso.
https://community.ubnt.com/t5/Instal...d/td-p/1203135
Re: Erro ROCKETs M5 "group key handshake completed"
Desabilita sua criptografia e verifique se o erro permanece.
Enviado via GT-I9515L usando UnderLinux App
Re: Erro ROCKETs M5 "group key handshake completed"
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
Re: Erro ROCKETs M5 "group key handshake completed"
@ab5x2 @rubem @1929 @Bruno
Se puderem, me deem uma luz.
Re: Erro ROCKETs M5 "group key handshake completed"
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.