AP MK OMNITIK desconectando clientes

[mayconff22]

---

Saudações a todos.

Estou com um problema no meu AP MK OMNITIK, sinal dos clientes bom, mas o AP desconecta eles do nada, não sei se alguém passou por esse problema ou conhece alguma solução, segue a print...



Já tentei setar o MCS manual, trocar canais, más até agora nada...

[ronei10]

Desconecta alguns ou todos? Ja testou com outra fonte. Uma UBNT por exemplo?

[mayconff22]

Saudações amigo, obrigado pela resposta.

Aparentemente o que tenho observado é que apenas clientes com UBNT AirGrid estão sofrendo com esses DC, você diz testar outro POE no AP?

[rubem]

Tem RX em -74dBm, outros em -67dBm, -66dBm, isso não são sinais muito bons não.

Põe pra exibir o CCQ, veja se o CCQ de RX desse pessoal com esse sinal não está ruim tipo 40%, se sim, isso é mais de metade dos pacotes perdidos! E o pacote que mais perde é o pacote grande, de navegação, ou seja, é navegar que cai.

Repara que os sinais mais baixos são uns que tem log de reassociação. Extensive data loss, perda excessiva de dados, isso são pacotes perdidos, que não tiveram resposta. E pacote sem resposta é quase sempre culpa de zona de fresnel ruim e/ou sinal baixo (Faz o pacote chegar em nível nem tão ruim, tipo -66dBm, mas com zona de fresnel parcial chega o sinal reto e também os reflexos nos obstáculos, torna o pacote ilegível)

Mas não é culpa do Omnitik, isso acontece com RB912 e setorial de R$ 1000. Não faz muito tempo vi isso em setorial UBNT, desconectando por sinal ruim.

Dá um duplo clique no cliente e veja o sinal no data rate usado, é bem capaz de, digamos, -66dBm, ser apenas o sinal de preambulo, e o sinal real no data rate em uso ser -72dBm. Tipo isso:

[mayconff22]

Tem RX em -74dBm, outros em -67dBm, -66dBm, isso não são sinais muito bons não.

Põe pra exibir o CCQ, veja se o CCQ de RX desse pessoal com esse sinal não está ruim tipo 40%, se sim, isso é mais de metade dos pacotes perdidos! E o pacote que mais perde é o pacote grande, de navegação, ou seja, é navegar que cai.

Repara que os sinais mais baixos são uns que tem log de reassociação. Extensive data loss, perda excessiva de dados, isso são pacotes perdidos, que não tiveram resposta. E pacote sem resposta é quase sempre culpa de zona de fresnel ruim e/ou sinal baixo (Faz o pacote chegar em nível nem tão ruim, tipo -66dBm, mas com zona de fresnel parcial chega o sinal reto e também os reflexos nos obstáculos, torna o pacote ilegível)

Mas não é culpa do Omnitik, isso acontece com RB912 e setorial de R$ 1000. Não faz muito tempo vi isso em setorial UBNT, desconectando por sinal ruim.

Dá um duplo clique no cliente e veja o sinal no data rate usado, é bem capaz de, digamos, -66dBm, ser apenas o sinal de preambulo, e o sinal real no data rate em uso ser -72dBm. Tipo isso:

Saudações amigo, obrigado pela resposta.

Em parte entendi, o cenário em que ocorre a situação é o seguinte:
Tenho a Omnitik em uma estação, os clientes que vi acontecer com frequência esse desconecte, o mais longe está a 1km com visada e os outros a 200,300,400 metros no máximo, com airgrid, visada 100%, mas ocorrem os DC.

Print do cliente mais longe:

Cliente perto, mas com sinal ruim na airgrid, até hoje não entendi o por que, deve ser algum ponto cego da antena:


Um dos cliente com airgrid a menos de 300 metros com visada (MCS setado manualmente):


Então não to entendo, se é o AP que não está dando conta, ou algo do tipo, todos esses e mais alguns ficam se desconectando, cliente reclamando de navegação lenta, que não abre nada, etc... obs. já fiz mudança de canais em tudo quanto é tipo, o melhor que achei foi este que estou usando.


Outra coisa que notei, em grande parte dos conectados o Tx/Rx Signal Strength Ch1 está com quase 20 dBm a mais em relação ao Ch0

[rubem]

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)

[mayconff22]

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.

[sorrivoip]

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)

me salvou...achei o cliente que estava derrubando td com essas dicas