Página 3 de 3 PrimeiroPrimeiro 123
+ Responder ao Tópico



  1. #13

    Padrão Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.

    Citação Postado originalmente por rubem Ver Post
    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!

  2. #14

    Padrão Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.

    Citação Postado originalmente por bhyll Ver Post
    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.



  3. #15

    Padrão 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

  4. #16

    Padrão Re: clientes caindo: unicast key exchange timeout e group key exchange timeout.

    Citação Postado originalmente por FMANDU Ver Post
    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.