Página 2 de 2 PrimeiroPrimeiro 12
+ Responder ao Tópico



  1. Curioso, os clientes Leander e Cleiton tem CCQ de TX ruim. O CCQ de RX está ótimo.

    Isso me diz que está perdendo pacote no trajeto torre>cliente (E no trajeto cliente>torre tá tudo ok).

    Esse "extensive data loss" tem vários motivos, é basicamente pacote sendo perdido, as vezes não tem relação APENAS com sinal ruim mesmo, pode ser um mix de zona de fresnel meia boca com alguma config. ruim pro sinal existente.

    Então acho que seria caso de mudar umas coisas no AP pra testar.

    Na aba Wireless:
    - Multicast Helper põe em disable. Isso só faz efeito em modo cliente e bridge.
    - Wireless Protocol testa se em ANY todos conectam.

    Na aba advanced:
    - HW retries aumenta pra 8 tentativas.
    - HW protection coloca em rts + cts
    - Adaptative noise imunity em ap + client
    - Preamble mode complica, short é pra CPE antiga, long é pra novas. Testa short primeiro. Se uns não conectarem testa long. Se outros não conectarem deixa em both (Ambos)
    - Disconnect timeout testa 10s (00:00:10)
    - On fail retry 20ms (0,2s)

    Na aba HT:
    - Marca todas as HT AMPDU priorities
    - HT guard interval cai no mesmo problema no preambulo, "ANY" é o modo compatível, se colocar em long terá data rates menores, teoricamente umas perdas de pacotes somem.

    Na aba TX power:
    - Testa potência fixa pra todos os datarates num número baixo tipo 18dBm, pra não ter alto consumo. As vezes o uso de potência alta gera umas perdas de pacotes.


    E nos clientes, está em modo cliente+wds? Se não estiver, testa.

    Alias, é autenticação PPPoE? Se for, a autenticação PPPoE acrescenta uns 28 bytes no cabeçalho normal, se limitar o MTU em número baixo no AP tipo 1500 pode ter problema, já que a CPE cliente pega o pacote de 1792 bytes do cliente, e acrescenta esse cabeçalho PPPoE na hora de transmitir, se o AP não aceitar pacote de, digamos, 1522 bytes, vai perder só os pacotes grandes.

    Talvez seria útil reduzir o MTU nos clientes pra 1472, e deixar o do AP em 1500 ou 1508, algo assim.

    Enfim, esse "extensive data loss" é fogo mesmo, em situação normal qualquer configuração funciona e não tem tanta perda a ponto de cair conexão, nesse caso o CCQ de TX é que está ruim então parece config. no Mikrotik da Omnitik.

    (E repito, ver isso em hardware de R$ 3 mil já vi muito, não é culpa de "fraqueza" da Omnitik. "Extensive data loss" em Basebox5 também acontece)

  2. Citação Postado originalmente por rubem Ver Post
    Curioso, os clientes Leander e Cleiton tem CCQ de TX ruim. O CCQ de RX está ótimo.

    Isso me diz que está perdendo pacote no trajeto torre>cliente (E no trajeto cliente>torre tá tudo ok).

    Esse "extensive data loss" tem vários motivos, é basicamente pacote sendo perdido, as vezes não tem relação APENAS com sinal ruim mesmo, pode ser um mix de zona de fresnel meia boca com alguma config. ruim pro sinal existente.

    Então acho que seria caso de mudar umas coisas no AP pra testar.

    Na aba Wireless:
    - Multicast Helper põe em disable. Isso só faz efeito em modo cliente e bridge.
    - Wireless Protocol testa se em ANY todos conectam.

    Na aba advanced:
    - HW retries aumenta pra 8 tentativas.
    - HW protection coloca em rts + cts
    - Adaptative noise imunity em ap + client
    - Preamble mode complica, short é pra CPE antiga, long é pra novas. Testa short primeiro. Se uns não conectarem testa long. Se outros não conectarem deixa em both (Ambos)
    - Disconnect timeout testa 10s (00:00:10)
    - On fail retry 20ms (0,2s)

    Na aba HT:
    - Marca todas as HT AMPDU priorities
    - HT guard interval cai no mesmo problema no preambulo, "ANY" é o modo compatível, se colocar em long terá data rates menores, teoricamente umas perdas de pacotes somem.

    Na aba TX power:
    - Testa potência fixa pra todos os datarates num número baixo tipo 18dBm, pra não ter alto consumo. As vezes o uso de potência alta gera umas perdas de pacotes.


    E nos clientes, está em modo cliente+wds? Se não estiver, testa.

    Alias, é autenticação PPPoE? Se for, a autenticação PPPoE acrescenta uns 28 bytes no cabeçalho normal, se limitar o MTU em número baixo no AP tipo 1500 pode ter problema, já que a CPE cliente pega o pacote de 1792 bytes do cliente, e acrescenta esse cabeçalho PPPoE na hora de transmitir, se o AP não aceitar pacote de, digamos, 1522 bytes, vai perder só os pacotes grandes.

    Talvez seria útil reduzir o MTU nos clientes pra 1472, e deixar o do AP em 1500 ou 1508, algo assim.

    Enfim, esse "extensive data loss" é fogo mesmo, em situação normal qualquer configuração funciona e não tem tanta perda a ponto de cair conexão, nesse caso o CCQ de TX é que está ruim então parece config. no Mikrotik da Omnitik.

    (E repito, ver isso em hardware de R$ 3 mil já vi muito, não é culpa de "fraqueza" da Omnitik. "Extensive data loss" em Basebox5 também acontece)
    Obrigado por dar uma luz ao problema amigo, vou testar suas recomendações de configurações, nos próximos dias posto o resultado do mesmo aqui, caso contrario vou ter que mudar o AP para Omni 13 dBi + Rocket m5 ou dois setoriais 120º + 2 Rocket m5.

    Muito obrigado pela atenção.






Tópicos Similares

  1. Respostas: 3
    Último Post: 02-04-2008, 09:39
  2. AP-MK ñ conecta mais de um cliente
    Por faieppi no fórum Redes
    Respostas: 3
    Último Post: 21-01-2008, 10:36
  3. 03 clientes em 01 AP + MK controlando tudo?
    Por SgtoMarlthon no fórum Redes
    Respostas: 3
    Último Post: 14-12-2007, 16:09
  4. Respostas: 8
    Último Post: 26-11-2007, 18:31
  5. Respostas: 3
    Último Post: 27-11-2006, 22:01

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L