Preciso da ajuda dos amigos aqui do forum urgente (Problema em 2.4)

Bom dia a todos os amigos do fórum Under Linux......


Bom aqui estou passando pelo seguinte problema, os clientes que estão na rede 2.4, estão conectando e desconectando da rede a todo instante,(coisa de 3 a 5 minutos);

Começou o problema na sexta feria, dia 1 de maio;

O cenário era o seguinte, uma RB 433 Ah com dois cartões xr2;

Troquei de canal, mudei configurações seguindo, tutoriais que os amigos deixaram aqui mesmo no fórum, e nada o problema persisti;

No desespero, tirei um dos cartões, e coloquei um Bullet no lugar de um dos cartões xr2... a principio estava normal, mais depois de alguns minutos o problema no bullet também apareceu.....

O estranho é que funcionou tudo normal com os cartões xr2 até mês passado, desde de 2012 eles estavam em produção na rede, quando montei o provedor, o único trabalho era mudar de canal para tentar fugir um pouco da interferência.

O que os amigos acham que pode está acontecendo?
Segue a baixo as imagens do nível de sinal dos clientes, lembrando que tem uma media de 20 clientes por cartão!Anexo 58854Anexo 58855...

Desde já grato a todos...

Até aqui o senhor me ajudou.....

Fiquem todos com Deus....

No Bullet apareceu cliente com sinal -23dBm, é isso mesmo?

Credo, esses 2 clientes estão GRITANDO no ouvido do Bullet (Que já é bem incompetente pra ser AP, é hardware pra cliente).

Tem que nivelar melhor esses sinais, no printo do Bullet aparecem 2 cliente GRITANDO em -23dBm e 1 sussurando em -69dBm, isso é uma diferença de 46dBm!!

Reduz a potencia desses clientes que estão gritando, se usar 802.11b (Parece que usa) coloque todos os clientes com potencia baixa o suficiente (Ou antena de ganho pequeno o suficiente) pra que cheguem na torre com sinal abaixo de -60dBm (Algo entre -60 e -65dBm tá ótimo).

Ter 1 cliente gritando e 1 sussurrando não é problema, mas quando enche isso e passa a ter 6 gritando e 6 sussurando aí a qualidade da rede cai demais. Cair a cada X minutos talvez não tenha relação com isso (Pode ser um hardware de cliente criando problemas), o normal quando tem toda essa diferença de sinal é ter CCQ bem baixo (Ou ping péssimo dá um ping -l 1400 rumo ao autenticador, a partir de um cliente (Não ping rumo a internet), verá algo tipo 4-10ms no ping normal (Digamos ping -t 192.168.1.1) mas 20-100ms no ping com 1400 bytes (Digamos ping -t 192.168.1.1 -l 1400). Ping de 100ms é sinal de rede péssima, e essa qualidade baixa não tem a ver com o equipamento usado, mas sim com configuração (Potencia adequada pra distancia, sem sinal muito alto nem muito baixo).

Citação:

---

Postado originalmente por rubem

No Bullet apareceu cliente com sinal -23dBm, é isso mesmo?

Credo, esses 2 clientes estão GRITANDO no ouvido do Bullet (Que já é bem incompetente pra ser AP, é hardware pra cliente).

Tem que nivelar melhor esses sinais, no printo do Bullet aparecem 2 cliente GRITANDO em -23dBm e 1 sussurando em -69dBm, isso é uma diferença de 46dBm!!

Reduz a potencia desses clientes que estão gritando, se usar 802.11b (Parece que usa) coloque todos os clientes com potencia baixa o suficiente (Ou antena de ganho pequeno o suficiente) pra que cheguem na torre com sinal abaixo de -60dBm (Algo entre -60 e -65dBm tá ótimo).

Ter 1 cliente gritando e 1 sussurrando não é problema, mas quando enche isso e passa a ter 6 gritando e 6 sussurando aí a qualidade da rede cai demais. Cair a cada X minutos talvez não tenha relação com isso (Pode ser um hardware de cliente criando problemas), o normal quando tem toda essa diferença de sinal é ter CCQ bem baixo (Ou ping péssimo dá um ping -l 1400 rumo ao autenticador, a partir de um cliente (Não ping rumo a internet), verá algo tipo 4-10ms no ping normal (Digamos ping -t 192.168.1.1) mas 20-100ms no ping com 1400 bytes (Digamos ping -t 192.168.1.1 -l 1400). Ping de 100ms é sinal de rede péssima, e essa qualidade baixa não tem a ver com o equipamento usado, mas sim com configuração (Potencia adequada pra distancia, sem sinal muito alto nem muito baixo).

---

Bom dia rubem, quando eu abri o tópico aqui no fórum, a primeira pessoa que eu achei que iria me ajudar, seria você rsrsrs, o problema é que eu não sei marcar a pessoa no tópico ainda rsrsrsrs......

Obrigado pela resposta, sou admirador do teu conhecimento.... Pra tudo que é lado tu sabe ajudar ao próximo , e tenho aprendido muito contigo.......

Bom voltando a pergunta, então ao seu ver no paniel que está a RB com xr2 estaria normal ?

Se o Bullet não é uma boa opção para se trabalhar em modo AP, qual seria um bom equipamento.....

Estou migrando os clientes para 5.8, mais alguns ainda não tem condições de comprar a antena!

DESDE JÁ GRATO A TODOS, QUE AJUDARAM.....

FIQUEM TODOS COM DEUS....

Só uma detalhe a mais: quando estava com os dois cartões, caia nos dois e ao mesmo tempo?

Sobre o problema do Bullet, ele é um hardware básico de 2006, o sucessor dele é o Bullet M2, já é de 2010.

Hoje o básico é NS LOCO M2, mas a uns 8 anos o que a UBNT produzia de mais barato/básico era os Bullet. A linha Bullet M2 melhorou muito porque agora o basicão é a linha LOCO.

Pra saber se o XR2 está ruim teria que testar mais, mas XR2 com defeito é coisa rara hein, acho que pra cada XR2 no defeito no mundo deve ter 2000 NS Loco M2 ou 2000 TL-WA5210g com defeito, acho mais provável que algum cliente esteja criando o problema (CPE ou roteador com problema), teria que ver trafego, ver se algum cliente varia de sinal e cia.

Também tem o seguinte: Com XR2 tinha cliente a no máximo -39dBm (Que é alto pra modo B), mas com o Bullet estão a -23dBm, isso não é diferença de sensibilidade, isso é porque mudou de cliente, modou de antena, mudou de cabo, ou mudou o mal-contato em cabo. São 16dBm de diferença entre um AP e outro, isso é muita coisa, acho que só problema em cabo, antena ou pigtail explica.
(A sensibilidade do radio é uma coisa, mas exibir sinais com 16dBm de diferença é outra, diferença de 2 ou 3dbm é o maximo que devia ter trocando de radio)


Alias, a RB onde estão os XR2 não está com capacitor estufado? A fonte que alimenta ela (E o Bullet hoje( não tem capacitor estufado? Depois de uns anos de calor é normal estufar capacitor, devia criar instabilidade mesmo, mas pelo que tenho visto cria é travamento na RB (Capacitor estufado, ou fonte com capacitor estufado) e não queda de cliente. Pra mim que queda de cliente é mais comum ser culpa de variação no sinal criada por cabo/pigtail ruim, e... com essa variação de sinal de -23 pra -39dBm eu só teria mais motivos pra desconfiar disso.

Que antena vc usa?

Citação:

---

Postado originalmente por 1929

Só uma detalhe a mais: quando estava com os dois cartões, caia nos dois e ao mesmo tempo?

---

Sim meu amigo...... Desse jeito que tu falou !!!

Já passou por isso ?


Desde já grato!!

Que Deus ajude a todos.....

Citação:

---

Postado originalmente por mathcardoso

Que antena vc usa?

---

Boa noite....

Dois Paineis OIW de 14 DBI;

Desde já grato amigo !!!

Que Deus lhe ajude sempre!!!

Citação:

---

Postado originalmente por rubem

Sobre o problema do Bullet, ele é um hardware básico de 2006, o sucessor dele é o Bullet M2, já é de 2010.

Hoje o básico é NS LOCO M2, mas a uns 8 anos o que a UBNT produzia de mais barato/básico era os Bullet. A linha Bullet M2 melhorou muito porque agora o basicão é a linha LOCO.

Pra saber se o XR2 está ruim teria que testar mais, mas XR2 com defeito é coisa rara hein, acho que pra cada XR2 no defeito no mundo deve ter 2000 NS Loco M2 ou 2000 TL-WA5210g com defeito, acho mais provável que algum cliente esteja criando o problema (CPE ou roteador com problema), teria que ver trafego, ver se algum cliente varia de sinal e cia.

Também tem o seguinte: Com XR2 tinha cliente a no máximo -39dBm (Que é alto pra modo B), mas com o Bullet estão a -23dBm, isso não é diferença de sensibilidade, isso é porque mudou de cliente, modou de antena, mudou de cabo, ou mudou o mal-contato em cabo. São 16dBm de diferença entre um AP e outro, isso é muita coisa, acho que só problema em cabo, antena ou pigtail explica.
(A sensibilidade do radio é uma coisa, mas exibir sinais com 16dBm de diferença é outra, diferença de 2 ou 3dbm é o maximo que devia ter trocando de radio)


Alias, a RB onde estão os XR2 não está com capacitor estufado? A fonte que alimenta ela (E o Bullet hoje( não tem capacitor estufado? Depois de uns anos de calor é normal estufar capacitor, devia criar instabilidade mesmo, mas pelo que tenho visto cria é travamento na RB (Capacitor estufado, ou fonte com capacitor estufado) e não queda de cliente. Pra mim que queda de cliente é mais comum ser culpa de variação no sinal criada por cabo/pigtail ruim, e... com essa variação de sinal de -23 pra -39dBm eu só teria mais motivos pra desconfiar disso.

---

Entende o que tu quis dizer da variação de sinais .....

Mais ali são duas antenas diferentes Rubem.....

Antes era assim..... 2 cartões xr2 em uma RB 433ah.... Começou a dar o problema citado acima.....

Ai eu tinha um bullet 2.4 aqui parado.... resolvi colocar o bullet no lugar de um dos cartões.....

agora ficou assim lado A bullet 2.4; lado B RB com xr2.....

Estou monitorando a rede aqui pra ver se tem cliente com rádio com defeito,
mais aparentemente está tudo normal!!!



Desde já grato amigo pela ajuda.....


Que Deus lhe abençoe pela ajuda!!

Citação:

---

Postado originalmente por RadNet

Sim meu amigo...... Desse jeito que tu falou !!!

Já passou por isso ?


Desde já grato!!

Que Deus ajude a todos.....

---

Aos poucos dá para ir filtrando e eliminando possiveis causadores.
Não é cartão, não é bullet.
Se fosse cartão caia num só. E como substituiu pelo bullet e cai ainda, o problema não está nem na RB.
Tá cheirando a energia....
Quando cai o pessoal já observou se a RB reiniciou, ou se o bullet reiniciou?

Revisa a alimentação

Se não reiniciaram pode ser outro problema que não energia.

Um detalhe: o cabo que desce da RB e o cabo que desce do Bullet estão entrando num switch? Se for também pode ser aí o problema

Citação:

---

Postado originalmente por 1929

Aos poucos dá para ir filtrando e eliminando possiveis causadores.
Não é cartão, não é bullet.
Se fosse cartão caia num só. E como substituiu pelo bullet e cai ainda, o problema não está nem na RB.
Tá cheirando a energia....
Quando cai o pessoal já observou se a RB reiniciou, ou se o bullet reiniciou?

Revisa a alimentação

Se não reiniciaram pode ser outro problema que não energia.

Um detalhe: o cabo que desce da RB e o cabo que desce do Bullet estão entrando num switch? Se for também pode ser aí o problema

---

Boa noite....

Os equipamentos não reiniciam amigo !!

E os equipamentos estão ligados direto na RB principal.....

Desde já grato...

Que Deus Ajude a Todos !

Citação:

---

Postado originalmente por RadNet

Boa noite....

Os equipamentos não reiniciam amigo !!

E os equipamentos estão ligados direto na RB principal.....

Desde já grato...

Que Deus Ajude a Todos !

---

Então dá para ir eliminando algumas possibilidades. Não é cartão e não é bullet. E como não reiniciam não é corte de energia.

Não é erro de configuração pois voce disse que estava tudo funcionando perfeito desde 2012.

Esta RB que recebe da RB com cartão e do Bullet, também não reiniciou? Creio que não

Fui agora rever o print do post inicial. Lá mostra que não houve desconexão na RB com cartão pois o primeiro está com 13hs de uptime.
Esta desconexão parece estar ocorrendo na RB concentradora.

Citação:

---

Postado originalmente por 1929

Então dá para ir eliminando algumas possibilidades. Não é cartão e não é bullet. E como não reiniciam não é corte de energia.

Não é erro de configuração pois voce disse que estava tudo funcionando perfeito desde 2012.

Esta RB que recebe da RB com cartão e do Bullet, também não reiniciou? Creio que não

Fui agora rever o print do post inicial. Lá mostra que não houve desconexão na RB com cartão pois o primeiro está com 13hs de uptime.
Esta desconexão parece estar ocorrendo na RB concentradora.

---

Bom dia amigo....

Não é na RB concentradora não , pois tenho mais 5 painéis com Rocket em 5.8, e não estou tendo problemas.....

acredito que seja alguma outra coisa.....


A única coisa acredito que seja, e cliente com radinho com defeito......

Só que ai teria que ter um cliente com defeito em cada painel.....


O que tu acha amigo ?


Desde já grato.....

Que Deus abençoe a todos!

Duvida boba: Sendo 802.11b, não tem cliente com USB ou PCI plugado nisso?

Porque malware que gera trafego GIGANTE em rede tem, e usando PCI ou USB é bem comum o usuário fuçar e colocar 2 ou 3 redes prioritárias na lista de conexão (Aí quando ele trava um AP ele conecta no outro).

É um ataque DDoS involuntário o que uns malwares fazem (A intenção é se proliferar geralmente, daria pra chamar de vírus se a intenção fosse apenas se proliferar, mas muitos tentam alterar dns de roteador ou coisa assim, são mais focados em gerar visitas pra páginas com adsense e cia). O único problema de USB e PCI (Ou CPE do cliente em bridge) é esse, todo o trafego do Windows infectado/mal-configurado bate lá no concentrador ou no AP de saída.

(O último episódio do ridículo CSI Cyber essa semana era sobre DDoS em wifi, por mais viagem-na-maionese que a parte técnica seja eles apontam uma coisa muito real: Um mísero smartphone pode detonar uma rede wifi, que dirá algo mais poderoso tipo ibm/pc)

Se todo mundo tem CPE roteada (Autentica a wan da CPE, e deixa a lan dela livre pro cliente) aí é de desconfiar da CPE em sí, teria que ver o trafego dos clientes (Em 802.11b trafego alto é 3-4Mbps).

Alias, 802.11b é bem parudo pra lidar com sinal ruim, sinal péssimo de -80dBm ou variando rapidamente (Por arvore no caminho, digamos) nem sempre é exibido como ruim, mas é péssimo, o lado ruim de ser um modo que aceita sinais horríveis é você descobrir quem está com o pior sinal, o CCQ em 802.11b é sempre baixo então não dá pra confiar só nele, de um duplo-clique nos usuarios na aba Registration e vai na aba Signal, lá vai ver o throughput, um throughput ruim pra 802.11b é menos de 6Mbps (O throughput REAL conseguível é 4Mbps, mas nessa aba Signal o que é exibido com sinal bom é 10-11Mbps mesmo, em PTmP eu sempre procurava ter pelo menos 8Mbps, isso que eu não trabalhava com zona de fresnel limpa nos clientes, mas limitava os sem-visada a 5 (De 20) por setorial, 802.11b permite uma rede lixo assim sem sofrer muito se vender planos lentos tipo menos de 500Kbps)

Citação:

---

Postado originalmente por RadNet

Bom dia amigo....

Não é na RB concentradora não , pois tenho mais 5 painéis com Rocket em 5.8, e não estou tendo problemas.....

acredito que seja alguma outra coisa.....


A única coisa acredito que seja, e cliente com radinho com defeito......

Só que ai teria que ter um cliente com defeito em cada painel.....


O que tu acha amigo ?


Desde já grato.....

Que Deus abençoe a todos!

---

Então sobram duas vertentes para investigar.

Esta que o Rubem falou e outra que seria entre a RB com cartão e o Bullet até o concentrador.
Revisa RJ45

Clientes com baixo nível de sinal prejudica muito a rede. Mas não acredito que ao ponto de reiniciar uma RB 433.

Então:

1. Analise e realize testes. Desligue um dos cartão e teste apenas um com os 20 clientes conectados. Veja se vai reiniciar. Depois desligue-o e ligue o outro e veja se também reinicia. Caso um cartao reinicie e outro nao, já isola o problema. Caso os dois estão reiniciando mesmo que sozinhos, o problema pode está em um aparelho danificado ou energia.

2. Tive o problema parecido em minha torre. Reiniciando direto meus equipamento. Troquei a fonte por uma com maior amperagem e também utilizei Fontes de computadores (fonte real 500w).

3. Verifique também as placa pci dos clientes ou AP.


Espero que ajude.

Atenciosamente,

O problema é que nem a RB com cartão nem o Bullet esta reiniciando.
E também não está reiniciando o concentrador, pois os que chegam de outros painéis estão normal.
E no registration do cartão mostra que não houve desconexão pois o uptime de um deles está com 13hs.

Está parecendo coisa de cortar só os dados. Não corta energia.
E está depois da Rb e Bullet e antes do concentrador.

Citação:

---

Postado originalmente por 1929

O problema é que nem a RB com cartão nem o Bullet esta reiniciando.
E também não está reiniciando o concentrador, pois os que chegam de outros painéis estão normal.
E no registration do cartão mostra que não houve desconexão pois o uptime de um deles está com 13hs.

Está parecendo coisa de cortar só os dados. Não corta energia.
E está depois da Rb e Bullet e antes do concentrador.

---

Bom dia a todos......

Agora o problema se agravou.....

Os clientes todos são desconectados da rede a após 3 segundos todos conectam novamente.....

A RB não reinicia.....

A interface do cartão também não some na RB.....


O que os amigos acham que pode ser?

Já troquei fonte.....


Desde já grato a todos.....
Que Deus ajude a cada um de vocês!!

Sendo 802.11b, testa isso na aba Advanced:
Anexo 59014

Mas pra ter desconexão no MK e TAMBÉM no Bullet eu diria que tem mais chance de ter cliente com USB ou PCI fazendo besteira na rede, faz controle por MAC, adiciona os MAC's dos clientes na aba registration, clica sobre o botão direito nele e dá um Connect to Acess List, aí no profile de segurança marca o Mac Accounting.
Pelo seguinte: Rede em bridge pode ser atacada com um falso servidor. Que eu saida só tem como dar um kick de mac por mac via wifi, mas programação não é minha area, não sei que firulas tem em distro tipo Kali Linux pra um engraçadinho fuçar na rede.

Alias... no log do MK não aparece nada interessante? Por mais que ocorre tanto no MK como no Bullet o log do MK pode ajudar, não lembro como é o detalhamento de log nos Bullet, mas em MK é logado o motivo da desconexão do cliente.

Alias n° 2... não tem nenhum script rodando? Script agendado pra dar kick em android e cia, AP 2,4GHz sempre tem curioso conectando, é bom limitar isso de alguma forma.
(Marca o Hide SSID, smartphones não conectarão, mas CPE's, roteadores e notebooks sim, já é um filtro muito bom contra curiosos)

Citação:

---

Postado originalmente por rubem

Sendo 802.11b, testa isso na aba Advanced:
Anexo 59014

Mas pra ter desconexão no MK e TAMBÉM no Bullet eu diria que tem mais chance de ter cliente com USB ou PCI fazendo besteira na rede, faz controle por MAC, adiciona os MAC's dos clientes na aba registration, clica sobre o botão direito nele e dá um Connect to Acess List, aí no profile de segurança marca o Mac Accounting.
Pelo seguinte: Rede em bridge pode ser atacada com um falso servidor. Que eu saida só tem como dar um kick de mac por mac via wifi, mas programação não é minha area, não sei que firulas tem em distro tipo Kali Linux pra um engraçadinho fuçar na rede.

Alias... no log do MK não aparece nada interessante? Por mais que ocorre tanto no MK como no Bullet o log do MK pode ajudar, não lembro como é o detalhamento de log nos Bullet, mas em MK é logado o motivo da desconexão do cliente.

Alias n° 2... não tem nenhum script rodando? Script agendado pra dar kick em android e cia, AP 2,4GHz sempre tem curioso conectando, é bom limitar isso de alguma forma.
(Marca o Hide SSID, smartphones não conectarão, mas CPE's, roteadores e notebooks sim, já é um filtro muito bom contra curiosos)

---

Boa tarde Rubem...

Vou fazer isso agora....

Tirei a tarde hoje para ficar monitorando esse rede 2.4.....

Obrigado pela ajuda...

Que o senhor jesus lhe ajude sempre.....

Desde já grato!!!!

Citação:

---

Postado originalmente por rubem

Sendo 802.11b, testa isso na aba Advanced:
Anexo 59014

Mas pra ter desconexão no MK e TAMBÉM no Bullet eu diria que tem mais chance de ter cliente com USB ou PCI fazendo besteira na rede, faz controle por MAC, adiciona os MAC's dos clientes na aba registration, clica sobre o botão direito nele e dá um Connect to Acess List, aí no profile de segurança marca o Mac Accounting.
Pelo seguinte: Rede em bridge pode ser atacada com um falso servidor. Que eu saida só tem como dar um kick de mac por mac via wifi, mas programação não é minha area, não sei que firulas tem em distro tipo Kali Linux pra um engraçadinho fuçar na rede.

Alias... no log do MK não aparece nada interessante? Por mais que ocorre tanto no MK como no Bullet o log do MK pode ajudar, não lembro como é o detalhamento de log nos Bullet, mas em MK é logado o motivo da desconexão do cliente.

Alias n° 2... não tem nenhum script rodando? Script agendado pra dar kick em android e cia, AP 2,4GHz sempre tem curioso conectando, é bom limitar isso de alguma forma.
(Marca o Hide SSID, smartphones não conectarão, mas CPE's, roteadores e notebooks sim, já é um filtro muito bom contra curiosos)

---

Amigo Rubem!

Coloquei as configurações que tu me passou, mais infelizmente, não sei o porque mais nem um dos clientes se conectaram a rede....
Tive que voltar as configurações, antigas !!!!


Desde já grato....

Obrigado pela ajuda...

Que o senhor Deus o ajude sempre !

Citação:

---

Postado originalmente por rubem

Sendo 802.11b, testa isso na aba Advanced:
Anexo 59014

Mas pra ter desconexão no MK e TAMBÉM no Bullet eu diria que tem mais chance de ter cliente com USB ou PCI fazendo besteira na rede, faz controle por MAC, adiciona os MAC's dos clientes na aba registration, clica sobre o botão direito nele e dá um Connect to Acess List, aí no profile de segurança marca o Mac Accounting.
Pelo seguinte: Rede em bridge pode ser atacada com um falso servidor. Que eu saida só tem como dar um kick de mac por mac via wifi, mas programação não é minha area, não sei que firulas tem em distro tipo Kali Linux pra um engraçadinho fuçar na rede.

Alias... no log do MK não aparece nada interessante? Por mais que ocorre tanto no MK como no Bullet o log do MK pode ajudar, não lembro como é o detalhamento de log nos Bullet, mas em MK é logado o motivo da desconexão do cliente.

Alias n° 2... não tem nenhum script rodando? Script agendado pra dar kick em android e cia, AP 2,4GHz sempre tem curioso conectando, é bom limitar isso de alguma forma.
(Marca o Hide SSID, smartphones não conectarão, mas CPE's, roteadores e notebooks sim, já é um filtro muito bom contra curiosos)

---

Olha o Log ai amigo Rubem.... olha se isso pode ajudar!


Anexo 59017

Desde já grato pela ajuda de todos !!

Que Deus ajude a todos !

So uma duvida a sua RB esta com a versão 5.4? ja tentou atualizar ela? pode parecer coisa boba, mas ja resolvi problemas parecidos com isso.

Hum, esse "Unicast Key Exchange Timeout" é erro antigo, desde muito antes de versão 5.x ou 4.x já viamos isso.
Não tenho muita certeza do que é a culpa, mas é erro que vem desde 3.x até hoje (6.x).

As vezes ele é causado por alterar o profile "Default" na aba Security Profiles.
Então deixar o profile "Default" sem mecher, e cria um NOVO pra usar.

Testa isso, novo profile com a config. que você usa, e deixa o profile chamado "Default" original.
(Alterar agora não sei se ajuda, eu particularmente nunca tive o problema)

Boa tarde @RadNet,

Pega todos os clientes que estão recebendo "deauth" e configura Watchdog no radio deles para um IP da sua rede (o teu gateway por exemplo). Após isso, vai bloqueando clientes que recebem "extensive data loss", até a rede ficar funcionando só com os clientes bons. Depois vai liberando devagarinhos os clientes que estavam com "extensive data loss" até o problema surgir novamente para descobrir qual é o cliente causador do problema. Um radinho cliente em modo bridge com um loop denro da rede do cliente vai gerar um trafego no seu ARP IMENSO que não vai aparecer no torch (a não ser que vc habilite o MAC Protocol) e vai derrubar a rede inteira, pois o trafego gerado é entre o radio do cliente e a sua torre, antes de chegar no concentrador que faz o controle de banda, ou seja, ele vai gerar muito mais trafego do que ele tem "direito" quando der problema desse tipo. E derruba as duas redes sim, pois o trafego gera uma interferencia imensa até para o outro painel que o cliente não está conectado, deixando ela deteriorada.

O foda é que no bullet, você não tem muita gerencia. Acho mais facil colocar os 2 XR2 denovo e fazer isso direto no mirkotik.

E o "sent deauth" é um outro problema, que pode estar relacionado a isso por um lado, mas que tu só vai resolver com watchdog.

Inquiery, nesta possibilidade que voce citou , derrubaria toda a rede?

Citação:

---

Postado originalmente por inquiery

Boa tarde @RadNet,

Pega todos os clientes que estão recebendo "deauth" e configura Watchdog no radio deles para um IP da sua rede (o teu gateway por exemplo). Após isso, vai bloqueando clientes que recebem "extensive data loss", até a rede ficar funcionando só com os clientes bons. Depois vai liberando devagarinhos os clientes que estavam com "extensive data loss" até o problema surgir novamente para descobrir qual é o cliente causador do problema. Um radinho cliente em modo bridge com um loop denro da rede do cliente vai gerar um trafego no seu ARP IMENSO que não vai aparecer no torch (a não ser que vc habilite o MAC Protocol) e vai derrubar a rede inteira, pois o trafego gerado é entre o radio do cliente e a sua torre, antes de chegar no concentrador que faz o controle de banda, ou seja, ele vai gerar muito mais trafego do que ele tem "direito" quando der problema desse tipo. E derruba as duas redes sim, pois o trafego gera uma interferencia imensa até para o outro painel que o cliente não está conectado, deixando ela deteriorada.

O foda é que no bullet, você não tem muita gerencia. Acho mais facil colocar os 2 XR2 denovo e fazer isso direto no mirkotik.

E o "sent deauth" é um outro problema, que pode estar relacionado a isso por um lado, mas que tu só vai resolver com watchdog.

---

Boa tarde amigo....

Vou fazer isso hoje a noite...
Obrigado pela dica....
Desde já grato Pela ajuda...

Que Deus lhe abençoe sempre !!!

Buenas @1929

Sim, derruba. Pois o cliente com problema, mesmo depois de cair, ligeirinho volta a reassociar e matar a rede novamente, e com isso vai matando todos os clientes conectados. Ja aconteceu comigo.
Não sei se esse é o caso do @RadNet, mas pelo visto ele ja testou muita coisa e não resolveu. A única coisa que ele parece não ter analisado foi justamente isso, alto trafego rolando nos radios que ele não esta vendo. Os torchs da vida geralmente não mostram, mas um loop tem grande possibilidade de gerar um ARP "bomb" na rede, e se for um cliente com sinal bom e boa capacidade de trafego, fode tudo.

Foi por isso que te perguntei. Pois ele tinha relatado pelo que entendi que isso só acontece de derrubar nestes dois painéis. O resto da rede continua normal.

De qualquer modo, é bem interessante esta sua colocação.

Buenas @1929

Na realidade, acho que agora que entendi sua pergunta. Não derruba a rede inteira não, achei que você se referia a rede wireless da POP onde está o cliente. Do radio que o cliente ta conectado pra frente, dai depende muito do cenário. Se no POP tem um NAS e/ou um roteador OSPF ou estático que seja, o roteador não vai propagar esse trafego não. Se, por outro lado, o radio que o cliente conecta está num switch, ele vai se propagar por onde tiver forward possível, se for switch normal, se propaga para todas as portas, se for gerenciavel, só pelas portas configuradas para receber forward da porta do radio. Numa rede bridge bem montada, o trafego alcançaria o backbone (o que não é muito bom, mas ja que é bridge...), porém, a gente tem que considerar que o trafego e PPS que os PTPs e o backbone suporta é muito maior do que o que o cliente suporta. Ou seja, ele derrubaria a POP pois em 2.4 só tem 2 canais que não se intercalam (isso se for em 20Mhz, se for 40Mhz, tudo interfere em tudo), o trafego do cliente geralmente ocupa muito tempo aéreo até pras antenas que não tem nada a ver com ele por isso.

Bom dia pessoal...

Vou colocar o Xr2 de volta, no outro painel....


Estou desabilitando todos os clientes que tem aquelas antenas aquário usb , e pci....

Acredito que seja, como já citado acima, algum cliente, com esse tipo de kit, fazendo besteira na Rede....

Obrigado pela ajuda de todos....

Que Deus abençoe a todos.....

Citação:

---

Postado originalmente por inquiery

Buenas @1929

Na realidade, acho que agora que entendi sua pergunta. Não derruba a rede inteira não, achei que você se referia a rede wireless da POP onde está o cliente. Do radio que o cliente ta conectado pra frente, dai depende muito do cenário. Se no POP tem um NAS e/ou um roteador OSPF ou estático que seja, o roteador não vai propagar esse trafego não. Se, por outro lado, o radio que o cliente conecta está num switch, ele vai se propagar por onde tiver forward possível, se for switch normal, se propaga para todas as portas, se for gerenciavel, só pelas portas configuradas para receber forward da porta do radio. Numa rede bridge bem montada, o trafego alcançaria o backbone (o que não é muito bom, mas ja que é bridge...), porém, a gente tem que considerar que o trafego e PPS que os PTPs e o backbone suporta é muito maior do que o que o cliente suporta. Ou seja, ele derrubaria a POP pois em 2.4 só tem 2 canais que não se intercalam (isso se for em 20Mhz, se for 40Mhz, tudo interfere em tudo), o trafego do cliente geralmente ocupa muito tempo aéreo até pras antenas que não tem nada a ver com ele por isso.

---

Muito boa sua explicação... Ele deve estar em bridge como a grande maioria. Uma estrutura mais profissional como você citou, evitando broadcasting e propagações indesejáveis normalmente é implantada depois, com mais conhecimento e experiencia.
Esta facilidade da rede em bridge é meio generalizada, inclusive aqui, hehehe
Esta nos planos uma mudança mas ainda não deu.

E como ele não reportou queda em outros painéis, só nestes dois, daí minha curiosidade. Gosto de acompanhar estes casos pois no final com a solução sempre se aprende alguma coisa.