Versão Imprimível
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
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:
Anexo 66441
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...
Primeira coisa que fiz..Citação:
Postado originalmente por fbsalvi
Engraçado que nem no forum oficial da ubiquiti, não existe uma explicação convincente para isso
passando por isso tb e tb nao obtive uma resposta sensata do forum delesCitação:
Postado originalmente por alextaws
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
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.
isto o conf fica no /tmp/system.cfgCitação:
Postado originalmente por ab5x2
eu tive este problema em um enlace no logo ele não pode fazer Handshake ai diminui a chave e funcionou, só não entendi o pq mais resolveu
Aqui uso um arquivo de configuração para CPEs ubiquiti, assim os técnicos vão apenas conectar no ssid, colocar usuario e senha, depois a identificação da antena.Citação:
Postado originalmente por ab5x2
aki tem 8 caracteres a chave e de 1 em 1 hora da esse log
Eu ia até trocar, mais depois que o @Lemaxtelecom, disse isso. Não sei mais, aqui também de uma em uma hora
da uma olhada no sinal
@Bruno, sim olhei
ai complicou
olhei tb
Então não é chave e também não deve ser ACK como foi comentado anteriormente, pois se acontece de hora em hora é cíclico e não depende de gargalo e nem de sinal que perde intensidade e consequentemente ACK precisaria ser um pouco maior para dar tempo da conexão manter a estabilidade. Duas hipóteses que devem ser eliminadas.Citação:
Postado originalmente por Lemaxtelecom
bom eu ja atualizei firmware , mexi no ack baixei potencia , e da na mesmaCitação:
Postado originalmente por 1929
Por isso que eu imagino que seja algo "cíclico", pois acontece de tempos em tempos determinados.Citação:
Postado originalmente por Lemaxtelecom
E o que tem de cíclico, cujo default geralmente é 1h mesmo, é a troca de chaves de criptografia.
Olhei aqui e Linksys e Open-WRT tem por default em 1h (3600s), em Mikrotik o "Group Key Update" por default está em 5 minutos nos 4 rádios que olhei, mas em roteador de mesa mais barato tipo Intelbras e TPlink tá lá o default em 86 mil segundos (24h). Se cai de hora em hora, e o log é de key handshake, então é isso.
Handshake por "Aperto de mão" não traduz bem, é a negociação/troca de chaves mesmo, seria isso aqui mais especificamente. Vejam que tem um ack no meio, um delayzinho extra pra dar tempo do rádio no outro lado processar a coisa (Senão entope o buffer com dados a analisar), por isso citei o aumento de ack timeout pra tentar quebrar um galho.
Em tese com WPA-TKIP era pra sumir o problema, e usar apenas WPA-TKIP gera uma rede que alguém com um pouco de insistência burla, mas mas WPA-TKIP e TAMBÉM PPPoE complica bastante, eu diria que deve ter 50 brasileiros que perderia tempo tentando burlar isso, então não sei se vale a pena ficar insistindo em WPA2-AES se tem algum problema (Mas até WEP troca chaves as vezes).
Pra mim fica claro que tem algo comendo processamento ou atrapalhando essa troca de chaves, não sei se seria excesso de clientes, excesso de clientes com data rates diferentes, excesso de perdas de pacotes em 1 ou 2 clientes, chipset de RF com problema de processamento ou alimentação (Ripple vindo do regulador de tensão), erro no firmware (Reset e atualização já foram feitos então não parece), mas no AirOS não tem muito o que mexer, eu diria que não tem nada pra mexer pra tentar diminuir o processamento do chipset ou esticar o tempo de troca de chaves, aparentemente o problema é que todos os rádios trocam chaves ao mesmo tempo, o AP não dá conta de negociar tanta chave aí dá erro mesmo.
(Se na conexão inicial conectasse um cliente a cada 10 ou 15 segundos, a troca de chaves também ocorreria a cada 10 ou 15 segundos (Um cliente por vez). Talvez daria pra rodar script pra kickar 1 cliente a cada 20s, na primeira hora, pro timeout das chaves depois não coincidir todos ao mesmo tempo, mas AirOS não tem script temporizado (E o kick derruba a conexão só na primeira vez, nas horas seguintes a chave é trocada sem cair conexão, a troca de chave na real não devia resultar em perda de conexão, poderia perder 1 ou outro ping mas os pacotes no buffer ethernet na verdade nem seriam perdidos, só teria delay enorme. No caso de MK o default de troca de chaves tá lá em 5 minutos (Group key update), e ninguém perde conexão a cada 5 minutos nem com 40 clientes por AP. E... se perder, ao menos o firmware não é capado, tem como aumentar isso pra DIAS, e tem como agendar script pra rodar no primeiro boot (Pra que as trocas depois não cheguem todos ao mesmo tempo, derruba os clientes em intervalos regulares pro timeout de chaves depois vir nos mesmos intervalos regulares)
mais uma aula... O Jamie que cuida dos interesses da Ubiquiti no Brasil precisava ler isso...
então como nosso amigo @rubem citou anteriormente, o bom seria se no AirOS tivesse uma opção para aumentar o tempo de troca de chave
apesar que vejo a troca mas os clientes realmente nao desconectam e @rubem , que explicação perfeita, postei os log no forum da ubiquiti e ate agora nenhum pronunciamento, vou aguardar
no meu tem ate um mac estranho aparecendo
Anexo 66506
no meu casa esta havendo desconexão.
O log "Group key handshake completed" indica que a troca de chaves terminou normal, que funcionou. Não podia cair.
O problema é o log "sent deauth", algo tipo "enviando desautenticação/desautorização", ele ativamente manda comando de desconexão pro rádio do clientes, por isso demora pra reconectar (Se tivesse caído, devia tentar reconexão em seguida. Se o AP "pediu pra você ir embora", a estação leva minutos pra tentar reconexão.
E pode ver que é o mesmo mac com desautenticação toda hora, deve ser sinal ruim, ou mac fora da ACL. Se fosse um log desse a cada 10 segundos seria proteção contra ataque DOS (Algum rádio com firmware com malware), mas nesse caso é um log de deauth a cada vários minutos, então é alguma CPE com sinal ruim demais ou senha configurada errada (Ou sem PPPoE), não chega a pesar nada.
Ter um log de "Group key handshake completed" e ficar sem conexão é um problema, quer dizer que não foi tão "completed" assim não, talvez o problema até nem seja a troca de chaves (Já que ele é logada com completa) e sim algo derivado delas, tipo alguma parte de uns pacotes vindo com criptografia "anterior" a troca de pacotes, não faço ideia de como ficam os cabeçalhos dos pacotes nesses casos.
@rubem, estranho isso pois tenho 35 setoriais em toda minha rede, na cidade que estou com problema, e todas 35 apresentam esse problema, então verifiquei outra cidade em que atendo, e o problema é o mesmo, a desconexão pppoe, acontece justo quando apresenta essa mensagem no log do rocket m5
Ah, perai, então se é o PPPoE que cai, porque a troca de chaves atrasou uns pacotes, um timeout mais longo no server PPPoE podia ser tentado.
No RouterOS testar Keepalive timeout de 10s pra 60s, ou mesmo 0s pra não dar timeout, esse tá mais fácil testar.
(Bota uns clientes em 60s, outros em 3600s, outros em 0 (Infinito), e acompanha no log)
Mas talvez que a troca de chaves wifi (Que são acrescentados no cabeçalho) o complica o cabeçalho PPPoE, e não seja questão de timeout.
Podem ser clientes com sinal ruim mesmo, acessei alguns aqui e o sinal estava oscilando bastante ,um ou outro que mesmo com sinal bom desconectavam mas deve ser por outros motivos, hj troquei equipamento de uma e ate agora , nada de desconexao,Citação:
Postado originalmente por rubem
@Lemaxtelecom. Cliente com sinal ruin não é, todos os clientes de determinada setorial cai, desde o cliente com -48 até o -65, desconectam e conectam ao mesmo instante.
@rubem, foi oque eu fiz antes de abrir tópico