Por isso que eu imagino que seja algo "cíclico", pois acontece de tempos em tempos determinados.
Versão Imprimível
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