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.