Erro ROCKETs M5 "group key handshake completed"

[Bruno]

Uma senha de 64 caracteres é dispendioso, pode diminuir isso pra 8 sim (qual o sentido de ter uma chave desse tamanho? Só complica pros técnicos decorarem ou ficar digitando).

A respeito de configurar via prompt do AirOS, deve ter algo no '/tmp/system.cfg'. Ao chegar na empresa vou dar uma olhada nisso.

isto o conf fica no /tmp/system.cfg

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

[alextaws]

Uma senha de 64 caracteres é dispendioso, pode diminuir isso pra 8 sim (qual o sentido de ter uma chave desse tamanho? Só complica pros técnicos decorarem ou ficar digitando).

A respeito de configurar via prompt do AirOS, deve ter algo no '/tmp/system.cfg'. Ao chegar na empresa vou dar uma olhada nisso.

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.

[Lemaxtelecom]

aki tem 8 caracteres a chave e de 1 em 1 hora da esse log

[alextaws]

Eu ia até trocar, mais depois que o @Lemaxtelecom, disse isso. Não sei mais, aqui também de uma em uma hora

[Bruno]

da uma olhada no sinal

[alextaws]

@Bruno, sim olhei

[Bruno]

ai complicou

[Lemaxtelecom]

olhei tb

[1929]

aki tem 8 caracteres a chave e de 1 em 1 hora da esse log

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.

[Lemaxtelecom]

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.

bom eu ja atualizei firmware , mexi no ack baixei potencia , e da na mesma

[1929]

bom eu ja atualizei firmware , mexi no ack baixei potencia , e da na mesma

Por isso que eu imagino que seja algo "cíclico", pois acontece de tempos em tempos determinados.

[rubem]

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)

[1929]

mais uma aula... O Jamie que cuida dos interesses da Ubiquiti no Brasil precisava ler isso...

[alextaws]

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

[Lemaxtelecom]

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

[Lemaxtelecom]

no meu tem ate um mac estranho aparecendo

[alextaws]

no meu casa esta havendo desconexão.

[rubem]

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.

[alextaws]

@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

[rubem]

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.