Evitar Deauth pois está causando latência alta a cada 20 segundos - Página 2
Evitar Deauth pois está causando latência alta a cada 20 segundos
mais uma perguntinha, como faço pra saber se ele ta usando o clocking ou não?
como configuro isso nos AP's?
clocking são aquelas conf de 10 ou 5 mhz do Mikrotik, por exemplo. Varios sistemas, que utilizam atheros dão suporte ao mesmo, variando o nome apenas. Desta forma basta apenas o AP e cliente suportarem essa conf.
23-06-2008, 10:58 #8
Barbaridade! Simplesmente não dá pra acreditar que seja um problema ser solução. Minha cidade é pequena e volta e meia enfrento isto, imagina quem tem torres em cidades com mais população que a minha que é de 6000 habitantes no centro e duvido que existam mais 300 computadores com algum sistema wireless.
Desculpe Sérgio, mas é difícil aceitar que simplesmente não poderei oferecer um serviço decente a meus clientes a não ser que tenha que fazer com que todos troquem seus equipamentos.
Desculpe, mas vou continuar tentando encontrar alguma forma de contornar os efeitos, se não posso evitar a causa. Pelo menos gostaria que meu mikrotik na torre não sofresse latência na comunicação por causa disto. Como disse, se tenho 3 segundos de latência a cada 20 quando ocorre este DeAuth de uma origem (acredito), se houver 5 ou 6 ataques simultaneos simplesmente fico com um serviço podre.
23-06-2008, 15:04 #9
Da uma olhada cara se o problema de deauth e de seus clientes ou de tentativa de invasao .. pois o mk tem varios problemas e esse e um deles..
23-06-2008, 15:13 #10
aqui eu fiz isso e amenizo BEM o Deauth.
e sergio, obrigado por dizer, tô testando uma torre 5.8 e já vo aplicar o mesmo :P
23-06-2008, 15:51 #11
Fiz isto, tava com periodic-calibration=enable, troquei para disable mas não mudou em nada, então voltei para enable. To às catas para solução do problema ainda. Obrigado pela ajuda.
23-06-2008, 19:36 #12
Flavio, infelizmente este é um problema de arquitetura, ou seja, do padrão 802.11 (culpa do IEEE, hehehehehehehe). Não é inerente a uma marca ou modelo de equipamento ou a algum sistema operacional em si. O problema é que os dados de enlace (MACs) correm livres pelo espectro/ar (sem cripto ou qualquer outra proteção), desta forma o atacante simplesmente precisa enviar um pedido de deauth, com o MAC de um cliente ou em alguns casos, usando aireplay nem isso precisa (apenas enviar o pedido de deauth). Como resolver? Usando protocolos e padrões proprietários, onde as conexões (enlace) são tratados de maneira diferente ou simplesmente o atacante não tem o mesmo equipamento com as mesmas configurações da sua rede.