clientes caindo: unicast key exchange timeout e group key exchange timeout.
Olá pessoal!
Sempre que vou colocar algum setor novo no ar, começa uma batalha!
Daí de tanto mexer acaba resolvendo, mas sem saber o que realmente fez resolver o problema!
Os clientes (airgrid m5, nanoloco m5, litebeam...) conectam na rede (basebox 5, rb912), com senha, e antes de se completar 24hs, todos disconectam, até que eu reinicie a rb, ou desabilite e habilite a interface wireless!
No log da rb aparece o seguinte erro registrado:
as vezes= unicast key exchange timeout.
as vezes=group key exchange timeout.
Percebo que é algo relacionado ao profile na segurança senha do wireless!
A rb ja foi atualizada, tanto a versão do mikrotik como o firmware da rb!
Isso ocorre tanto em versões 5.xx, como em versões 6.xx!
Trata-se de um problema aleatório, não tem hora exata de acontecer, e também não escolhe clientes!
Ja peguei as regras exportadas de outra rb, que foi resolvido o problema, e inseri na rb com problema, com as regras iguais, mas as quedas continuam!
Por favor, me ajudem galera!
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Bom dia amigo,
Já tentou gerar uma nova criptografia e trocar no rádio do cliente, esse unicast key exchange timeout até onde sei é erro de criptografia.
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
E em versões mais velhas o problema era mexer no profile default de criptografia, o único jeito de não dar isso pra mim algumas vezes foi deixar o profile default quieto, do jeito que vem depois de resetar, e criar novo profile pra mexer.
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Vc utiliza PPPoe, certo?
Então que eu saiba utiliza-se uma só criptografia por cliente, não tem como ele estar renovando a criptografia, até pq o sistema integrado a sua rede gera essa criptografia e é uma só desde que vc instala o cliente ou vc pode gerar uma nova caso seja necessário.
Eu trabalho com o MK solutions e funciona basicamente desta forma.
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Citação:
Postado originalmente por
rubem
E em versões mais velhas o problema era mexer no profile default de criptografia, o único jeito de não dar isso pra mim algumas vezes foi deixar o profile default quieto, do jeito que vem depois de resetar, e criar novo profile pra mexer.
Oi rubem!
Eu também não mexo no profile default!
Sempre crio outro!
Me parece que é algo relacionado com a ordem em que é criada as regras desse novo profile!
Falo isso porque, vejo que em alguns APs, la na aba EAP, no campo EAP Methods, hora o campo aparece escrito ofuscado (cinza, tipo desabilitado), e hora aparece com uma escrita mais forte!
Muito estranho!
Inclusive, de ontem pra hoje, parou de cair! De tanto que eu mexi, devo ter acertado a regra, mas não sei qual foi a solução!
Seria bom sabermos o que realmente causa isso! Vejo muita gente citando o problema, mas sem retorno, até mesmo do suporte da mikrotik!
Obrigado!
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Citação:
Postado originalmente por
juliano1393
Vc utiliza PPPoe, certo?
Então que eu saiba utiliza-se uma só criptografia por cliente, não tem como ele estar renovando a criptografia, até pq o sistema integrado a sua rede gera essa criptografia e é uma só desde que vc instala o cliente ou vc pode gerar uma nova caso seja necessário.
Eu trabalho com o MK solutions e funciona basicamente desta forma.
Oi Juliano!
Sim, utilizo pppoe!
Mas a autenticação do pppoe não tem nada a ver com a senha do wireless!
Meu problema não é autenticação do pppoe!
Acho que pra vc sim, porque vc utiliza um sistema que integra tudo!
Imagina assim: meu ap como um roteador do cliente, liberando sinal e pedindo uma senha unica pra cada cliente que quiser conectar! Quem tiver a senha correta entra, logo depois ele passa a discar a autenticação do pppoe, dai sim, ele pede pro server pppoe, e se tiver tudo correto autentica e libera navegação!
O problema é algo relacionado no profile da segurança do wireless do AP!
T+
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Citação:
Postado originalmente por
juliano1393
Bom dia amigo,
Já tentou gerar uma nova criptografia e trocar no rádio do cliente, esse unicast key exchange timeout até onde sei é erro de criptografia.
Ola!
A criptografia esta correta!
Os clientes conectam e navegam na net, mas me parece que da um certo timer, e o ap quer tipo renovar a criptografia deles, e é aí que derruba todo mundo!
Vc esta certo! Quando tem alguem com senha errada, no log dá o mesmo registro que vc citou!
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Isto é problema de transmissão.
Quando ocorre algum problema de transmissão quando você esta fazendo um download por exemplo, dependendo do tempo o Download da erro de Timeout, pois esperou muito tempo sem receber dados.
Na questão de troca de chaves é a mesma coisa, porém o tempo de timeout é muito menor, e o resutlado é derrubar o link JUSTAMENTE por segurança. Se o AP tenta fazer a troca de chaves de o cliente não responde, por um breve período de alguns milisegundos que o link não conseguiu comunicar por qualquer motivo que seja, o AP derruba aquela associação, pois ela ficaria fora de sincronia com as chaves e não conseguiria trafegar mais nada reconhecível.
Muitas vezes apenas trocando o canal resolve pois o problema pode ser no canal sendo usado, porém, mexer nas chaves em só não vai resolver, a não ser que você simplesmente desabilite a autenticação da wireless, assim, ela não vai cair por esse problema, porém, os dados trafegando não terão nenhuma criptografia, o que é um problema de segurança. Mas... se você autentica seus clientes por PPPoE e usa criptografia no PPPoE, então mesmo que a wireless não possua criptografia, você ainda vai ter um layer de segurança na criptografia do PPPoE.
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Citação:
Postado originalmente por
inquiery
Isto é problema de transmissão.
Quando ocorre algum problema de transmissão quando você esta fazendo um download por exemplo, dependendo do tempo o Download da erro de Timeout, pois esperou muito tempo sem receber dados.
Na questão de troca de chaves é a mesma coisa, porém o tempo de timeout é muito menor, e o resutlado é derrubar o link JUSTAMENTE por segurança. Se o AP tenta fazer a troca de chaves de o cliente não responde, por um breve período de alguns milisegundos que o link não conseguiu comunicar por qualquer motivo que seja, o AP derruba aquela associação, pois ela ficaria fora de sincronia com as chaves e não conseguiria trafegar mais nada reconhecível.
Muitas vezes apenas trocando o canal resolve pois o problema pode ser no canal sendo usado, porém, mexer nas chaves em só não vai resolver, a não ser que você simplesmente desabilite a autenticação da wireless, assim, ela não vai cair por esse problema, porém, os dados trafegando não terão nenhuma criptografia, o que é um problema de segurança. Mas... se você autentica seus clientes por PPPoE e usa criptografia no PPPoE, então mesmo que a wireless não possua criptografia, você ainda vai ter um layer de segurança na criptografia do PPPoE.
Bom dia!
Vou discordar de você!
Pois este AP, conta com uma transmissão perfeita!
Todos os clientes (em torno de 18), estão com sinal entre-55 a -63!
A RB esta trabalhando em 24v, e amperagem de sobra! Não houve nenhum desligamento, pra dizer que é problema falta de energia!
Clientes setados com velocidade de 1mb!
Ping interno 3 a 5 ms!
Pra mim, que quando é erro de transmissão ele da extensive data loss la no log!
Neste momento meu problema esta solucionado, ja estao conectados ha 2 dias, mas resolveu depois de tantas mexidas que dei no profile de segurança wireless!
Mexi tanto que nem sei o que foi alterado!
Obrigado!
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Buenas @bhyll
Os problemas de transmissão não se resumem a sinal baixo e/ou problemas de alimentação.
Além disso, "extensive data loss" é um indicativo de problema de transmissão também, porém mais evidente. Problemas de momentos curtos as vezes inperceptíveis a nível de usuário que dão problema nas trocas de chaves e consequentemente fazem o AP desassociar, são os mesmos, porém que ocorrem no momento da troca de chave, e que talvez nem sejam grandes o suficiente para gerar um "extensive data loss".
Imagina que tu grita pra um cara la na frente um código (que o código para "tradurzir" o que tu vai falar a seguir), dai o cara escuta, anota, e tu começa a falar e ele vai entendendo tudo. Dai tu grita o código pra outro, e ele não responde (por não ter escutado), o que vai acontecer, é que ele não vai entender nada que tu falar, pois ele não conhece o código.
Mexer nas chaves, por isso, não resolve. O que as vezes acontece muito é você ficar mexendo por um grande período em configs e a origem que estava gerando o problema de comunicação não existe mais, o que faz desconfiar que o problema foi "resolvido", quando na verdade ele nunca foi endereçado.
Mas se ja está funcionando tranquilo pra você ta beleza. E caso de isso denovo, tente trocar só o canal, muitas vezes resolve.
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Pessoal, olha o problema novante!
Voltou a derrubar os clientes!
Agora percebi o seguinte: a rb basebox5 esta com a versão 6.32.2, igual a versão de outras rbs que não apresentam o problema!
Mas observei que na interface wireless, na aba General, no campo L2 mtu, esta com valor 2290, e não é possivel altera-lo! Só consigo alterar o nome da interface, que atualmente esta como wlan1!
Ja nas outras rbs, que estão normais, o valor esta preenchido 1600, e o campo esta editavel, podendo ser alterado seu valor!
Que M### pode ser isso?
Ja tentei alterar via terminal e nao consegui!
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Esses 1600 não é o l2mtu nas lan? Porque o que acessei de RB912 aqui tem L2MTU na WLAN de 2290 e 1600 é na lan.
(A WLAN só vai receber pacote maior de 1600 (Pra repassar pra lan) se a CPE do cliente estiver configurada pra isso, e o default de CPE básica é l2mtu na casa dos 1522)
Geralmente isso é dado que vem do chipset (wlan no chipset de RF, lan no controlador ethernet interno do chipset ou avulso), é fixo no firmware chipset, por isso não é alterável no sistema operacional. Conforme a versão da RB pode ter outra implementação do chipset e permitie alteração, mas no geral o l2mtu é imexível mesmo.
E em teoria qualquer valor acima de 1530 poderia criar quebra de pacote, já que mesmo com vlan e pppoe é difícil um pacote vindo de CPE comum passar de uns 1520 a 1522B. Se com 1600 não há quebra, também não devia haver com 2290.
AS VEZES você seta o MTU (Não o L2MTU) pra coisa tipo 1494 bytes e perde uns pings, seta pra 1942 e não perde nada, idem pra 1470 e 1472, parece que alguns tamanhos específicos quebram parte do cabeçalho por isso gera perda do pacote como um todo. Nunca resolvi problema mexendo nisso, mas CRIAR problema mudando um MTU default de 1500 pra 1498 ou 1502 já criei.
Se tiver acesso remoto às CPE's, dá pra testar fixar o MTU delas em 1492. Elas tem só 1 conexão pra cuidar, elas podem quebrar pacotes e depois juntar, tem tempo de sobra pra isso.
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Citação:
Postado originalmente por
rubem
Esses 1600 não é o l2mtu nas lan? Porque o que acessei de RB912 aqui tem L2MTU na WLAN de 2290 e 1600 é na lan.
(A WLAN só vai receber pacote maior de 1600 (Pra repassar pra lan) se a CPE do cliente estiver configurada pra isso, e o default de CPE básica é l2mtu na casa dos 1522)
Geralmente isso é dado que vem do chipset (wlan no chipset de RF, lan no controlador ethernet interno do chipset ou avulso), é fixo no firmware chipset, por isso não é alterável no sistema operacional. Conforme a versão da RB pode ter outra implementação do chipset e permitie alteração, mas no geral o l2mtu é imexível mesmo.
E em teoria qualquer valor acima de 1530 poderia criar quebra de pacote, já que mesmo com vlan e pppoe é difícil um pacote vindo de CPE comum passar de uns 1520 a 1522B. Se com 1600 não há quebra, também não devia haver com 2290.
AS VEZES você seta o MTU (Não o L2MTU) pra coisa tipo 1494 bytes e perde uns pings, seta pra 1942 e não perde nada, idem pra 1470 e 1472, parece que alguns tamanhos específicos quebram parte do cabeçalho por isso gera perda do pacote como um todo. Nunca resolvi problema mexendo nisso, mas CRIAR problema mudando um MTU default de 1500 pra 1498 ou 1502 já criei.
Se tiver acesso remoto às CPE's, dá pra testar fixar o MTU delas em 1492. Elas tem só 1 conexão pra cuidar, elas podem quebrar pacotes e depois juntar, tem tempo de sobra pra isso.
Ola rubem!
O L2mtu estava 1600 na lan e na bridge, ja na wlan estava esses 2.2xx!
E nessa wlan não era possivel alterar este campo!
Agora atualizei pra 6.35.4, e o l2mtu ficou 1600 em tudo, e com possibilidade de altera-los! Deve ser bug da versão! Mas tenho essa versão em outras basebox5 e não da esse problema!
Quanto ao problema do Ap derrubar os clientes e marcar unicast key exchange timeout e group key exchange timeout no log, e enquanto eu não reiniciar a rb pros clientes voltar a conectar, esse problema ainda não foi resolvido!
Chegou a ficar 2 dias sem o problema!
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Citação:
Postado originalmente por
bhyll
Ola rubem!
O L2mtu estava 1600 na lan e na bridge, ja na wlan estava esses 2.2xx!
E nessa wlan não era possivel alterar este campo!
Agora atualizei pra 6.35.4, e o l2mtu ficou 1600 em tudo, e com possibilidade de altera-los! Deve ser bug da versão! Mas tenho essa versão em outras basebox5 e não da esse problema!
Quanto ao problema do Ap derrubar os clientes e marcar unicast key exchange timeout e group key exchange timeout no log, e enquanto eu não reiniciar a rb pros clientes voltar a conectar, esse problema ainda não foi resolvido!
Chegou a ficar 2 dias sem o problema!
@bhyll Resolveu o problema? Tenho um Groove com a mesma frescura na versão 6.37.5 bug fix.
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Estou com esse mesmo problema e não acho a solução, simplesmente os clientes desconectam da wireless e no log diz: gateway: disconnected, group key exchange timeout
Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.
Citação:
Postado originalmente por
FMANDU
Estou com esse mesmo problema e não acho a solução, simplesmente os clientes desconectam da wireless e no log diz: gateway: disconnected, group key exchange timeout
Em um ponto de acesso rural nosso começou a dar isso semana passada também. Depois de 5 minutos conectados, a maioria dos clientes desconectava com esse erro no log e não voltavam mais a não ser que eu desativasse e reativasse a wlan ou fizesse alguma alteração na configuração do wireless.
Não é bem uma solução, mas a única coisa que fez isso parar foi aumentar lá no security profile o Group Key Update. Estava o valor padrão de 5 minutos, o que coincidia com o intervalo das desconexões. Aumentei para 30 minutos, e até monitorei se isso só não ia fazer demorar 30 minutos para desconectar, mas não aconteceu mais depois da alteração e está assim até hoje.
