Bem-vindo à Comunidade UBNT

Tempo de monitoração do RSSI

Boa tarde.

 

Estou querendo modificar a configuração do RSSI da minha rede. Já segui todo o passo a passo do forúm na configuração do arquivo config.properties, reprovisionei o meu AP de teste e no shell do AP digitei o comando:

 

ps | grep stamgr

 E ele me retorna a saída certa de que o serviço está reconfigurado.

 

17617 admin 1260 S /bin/stamgr -i 1 -b ng -r 75 -n 0

 

Eu sei que os APs tem um tempo de monitoramento padrão para conferir o RSSI e se necessário reenviar um pacote de autenticação para o dispositivo do usuário semelhante ao reconnect da GUI.

 

Minha pergunta é, existe alguma forma de alterar este tempo de monitoramento? Algum arquivo, função, script ou comando?

 

Desde já, muito agradecido.

 

Comentários

  • R4V3RR4V3R 8513 Pontos

    Olá @narangomes bem vindo à comunidade.

     

    A sua configuração de MINRSSI parece estar aplicada, porém está completamente incorreta. Você configurou como 75, o que é complemente fora de qualquer padrão. Lembre-se que este número não é o sinal que o cliente recebe, mas a diferença entre o sinal que o cliente recebe e o noise floor no local, que não é fixo, mas sim dinâmico. A Ubiquiti recomenda utilizar este número em 20, e eu recomendo que apenas mude este número se você souber exatamente o que está fazendo.

  • Bom dia R4V3R.

     

    A princípio eu coloquei um valor assim tão alto porque os testes que eu estou realizando não são na rede mesmo, mas em uma pequena rede de teste com um servidor (Windows) e 2 APs dentro do laboratório, e eu tenho um espaço restrito para locomoção então para que eu pudesse ver a reação do dispositivo à aplicação da regra, o RSSI não poderia estar muito baixo, por isso esse número tão alto.

    Mas eu esqueci de levar em conta que o ruído é muito dinâmico e não depende simplesmente da distância que o dispositivo está do aparelho.

  • R4V3RR4V3R 8513 Pontos

    Ele simplesmente não vai funcionar desta forma, é basicamente impossível você conseguir 75dBm de SNR, sendo que normalmente, se você estiver logo abaixo do AP, o SNR deve ser algo em torno de 50.

  • Mas o valor do RSSI não é igualmente equivalente ao do SNR como mostra na tabela do fórum RSSI 75 = 35 SNR. Por isso não seria fisicamente impossível atingir esse valor.

  • R4V3RR4V3R 8513 Pontos

    Não você não entendeu, mas também não é culpa sua, e sim da Ubiquiti que complicou as coisas desnecessariamente...

    Vamos lá, conceitualmente, RSSI e SNR são coisas bem distintas, mas a função MINRSSI usa na verdade o SNR como base, não RSSI.

    RSSI é o sinal percebido pelo cliente, SNR é a diferença entre o RSSI e o noise floor em um determinado canal, e uma determinada área, em um determinado momento, portanto é dinâmico. Para configurar a função MINRSSI você coloca o número que aparece na coluna SNR, mas isso não quer dizer que o RSSI vai ser sempre aquele pois o noise floor se modifica. Aquela tabela indica apenas o valor que a controladora mostra na interface, ou seja, pra aparecer que o cliente está com sinal de 99%, precisa de pelo menos 45 de SNR.

    Se você quer realmente testar o recurso, recomendo que coloque algo entre 30 e 40 e comece a se afastar lentamente do AP, e para acompanhar em tempo real, conecte-se ao AP por SSH e use o seguinte comando:

    stamgr -a

     Ele irá lhe mostrar em tempo real o SNR de todos os clientes conectados, bem como uma montanha de informações adicionais, este recurso é muito útil e sempre utilizo quando faço um site survey.

  • Boa tarde, R4V3R.

     

    Não entendi porque o RSSI não será sempre o mesmo pelo fato do noise floor se modificar. Se o RSSI é o sinal recebido pelo cliente e não a diferença entre o sinal recebido e noise floor, porque o RSSI sofreria alguma variação causada pelo noise floor?

    E no retorno do comando:

    # stamgr -a

     O número do campo rssi na verdade usa o valor no SNR?

    npe idle= 5 rssi=48 58/ 24 ccq= 900 tx/ret/queued= 0/ 0/ 0 rx/ret/mc= 0/ 0/ 0 err= 0/0

     

  • R4V3RR4V3R 8513 Pontos

    Cara, é difícil explicar, porque na verdade estou te explicando algo que é errado, mas a ubnt fez desta forma. O que se modifica não é o RSSI, mas sim o SNR. O que eu quis dizer é que apesar da função se chamar MINRSSI, ela usa na verdade o valor do SNR, e não RSSI, entendeu? O correto seria ela se chamar MINSNR, seria menos errado no caso.

    Exatamente como está na tabela que você está vendo, aonde está escrito RSSI, é na verdade o valor do SNR. A ubiquiti usa os termos RSSI e SNR como se fossem sinônimos, tendo ambos o significado do SNR, o que não é verdade, e aquela tabela que há na base de conhecimentos apenas complica as coisas, principalmente para quem já é familiar com estes termos em equipamentos de outras marcas.

     

  • Complica mesmo. Então o valor setado no arquivo config.properties na verdade é o SNR mínimo e uma numeração menor de SNR desabilitaria o dispositivo.

     

    Mas no recurso:

    stamgr -a

     onde eu encontro o valor de SNR em tempo real? 

  • R4V3RR4V3R 8513 Pontos

    narangomes wrote:

    Complica mesmo. Então o valor setado no arquivo config.properties na verdade é o SNR mínimo e uma numeração menor de SNR desabilitaria o dispositivo.


    Exatamente.


    narangomes wrote:

    Mas no recurso:

    stamgr -a

     onde eu encontro o valor de SNR em tempo real? 


    Pois é, o valor do SNR está justamente no campo RSSI :mad2:

    É este valor que se configura no MINRSSI :cuss:

  • Estou com essa dúvida pois quando eu configurei o meu arquivo com 75 para fazer o teste você disse que era impossível chegar a esse nível porque embaixo do AP o máximo que o dispositivo conseguiria era 50, mas ao fazer um teste aproximando um dispositivo do AP o campo rssi desse dispositivo chegou a mostrar até 81.

  • R4V3RR4V3R 8513 Pontos

    Impossível não é, eu disse que era quase impossível, principalmente em 2.4Ghz. Eu fiz um teste semelhante esta semana, e o máximo que vi foi algo em torno de 63, mas este número oscila obviamente, mas talvez em 5Ghz com noise floor menor 75 seja possível, mas ainda assim não é viável. Eu estou tentando te explicar o que é viável, não possível, e como a ubiquiti recomenda como valor padrão 20, algo realmente prática não deve passar de 40, senão você vai ter problemas, te adianto porque já trilhei este caminho...

    Se você configurar MIRSSI muito alto ou load balance muito baixo, seus clientes irão ficar pulando de um AP para o outro e isso irá causar problemas constantes em sua rede..

  • É verdade existe o outro extremo.

    Eu vou fazer o teste na rede dessa vez com um valor entre 20 e 30 para ver os resultados.

    Muito obrigado pelas respostas. Não sei se imediatamente após ele captar um número menor doque o que foi configurado o AP envia o pacote de autenticação para o disposito, ou quanto tempo ele espera para fazer isso, mas, pelo menos o intervalo do tempo de monitoração da função é o parametro -i que como padrão começa com 1 segundo.

Entre ou Registre-se para fazer um comentário.