+ Responder ao Tópico



  1. #1

    Padrão Problema com Radius!!!

    Pessoal to com um problema bem esquisito... seguinte, temos um servidor Radius rodando e autenticando PPPoE. até ai tudo ok. O problema é que ele checa no banco de dados se o "AcctStopTime = 0". Se for ele não permite uma nova conexão. (possivelmente o cliente ainda esta logado e deve ser outra pessoa tentando logar).
    blz, o problema é que quando cai a conexão ou o cara desliga o pc sem desativar o pppoe, a sessão não é fechada no banco de dados, e dai o cara vai conectar e da erro pq o AcctStopTime = 0. Para piorar tem uma tabela no radius que ele tbm faz este controle, e da mesma coisa, como não fecha nele tbm da erro...
    Portanto temos 2 erros..

    Aguem ja passou por isso?

    Vlw

  2. #2

    Padrão

    to tendo um problema parecido... e ainda nao consegui resolve, eu uso o hotspot + freeradius

    falow

  3. #3

    Padrão

    então o idle time do mikrotik não adianta pro radius, nem a opção only one do pppoe server... alguem tem alguma ideia?

  4. #4

    Padrão

    voce pode usar SNMP para ver quem esta conectado no MK por pppoe ou por hotspot...

    basta voce achar as OID corretas.
    e fazer um script para freeradius executar n autenticacao.
    desta forma voce nao consultando local, e sim o MK. é muito mais seguro e funcional
    ai voce pode tira o Simultaneous-Use do freeradius...

    no radius tem um parametro Exec-Program-Wait
    acho que é isso..
    com ele voce muitas possibilidades..
    porque ele vai pssar os parametros para o seu script.
    eu aqui fiz um script em perl
    que checa os usuarios no MK,, checa macaddress previamente cadastrado em banco de dados, entre outras checagem, para poder autorizar o cliente a se conectar.

  5. #5

    Padrão

    LCP: PPP Link Control Protocol Overview (RFC 1570)


    Existe esse protocolo que serve justamente pra isso.

    Se configurado no servidor PPP, é enviado um pacote com ECHO.
    Se o echo for respondido, tudo continua bem, se nao for correspondido, é enviado mais 3. Se esses 3 nao forem respondidos, a conexao PPP é fechada (e consequentemente o radius tambem é liberado) .

  6. #6

    Padrão

    hummmmm legal,...

    tipo, o snmp, o pessoal aqui ja pensou nisso, so que não gostariamos de usar pq tem uma grande parte da rede em bridge, e ai fica muita sujeira...

    agora o LCP vou dar uma pesquisada....

    vlw

  7. #7

    Padrão

    com o pppoe tambem pode acontecer o mesmo problema..
    o pppoe é muito bom..
    mas a rede de radio tem que estar OK
    no cliente nao pode ficar perdendo ping, se nao a conexao pppoe ja era..
    cai mesmo

  8. #8

    Padrão

    então quanto a isso a parte de radio nem tem tampo problema, pq se tiver perdendo pacote a cnexão eh fechada... da "peer is no responding". O problema eh quando o cara mete o dedao no power, ou da um pico de energia... ai tem que resolver tudo manualmente.

  9. #9

    Padrão

    Eu tinha esse problema com os meus BSDs.

    Eu ativei o LCP ECHO e nunca mais me encomodei...

    Existe um timeout tambem.

  10. #10

    Padrão

    andei procurando mas num achei...
    pessoal o LCP vc ativa no servidor ou no RADIUS? no meu caso uso Mikrotik, aparentemente não tem LCP... tem como fazer isso no Radius mesmo?

  11. #11

    Padrão

    Isso é caracteristica do PPP.