Pedro, acredito que essa aqui só você possa responder (mas se alguém mais souber, agradeço pela resposta também, hehehehe):

Por que o MK-Auth adiciona o lease na RB certinho na próxima vez que o cliente faz login após eu alterar o IP e MAC dele pelo sistema, mas se eu alterar essas informações pelo banco de dados na tabela sis_cliente isso não ocorre (MK-Auth não manda o lease para a RB)?

Há algum outro campo que acaba ficando desatualizado quando eu altero pelo banco de dados, e que é usado pelo MK-Auth no momento que o cliente faz login para determinar se vai enviar o lease? Poderia dizer, para que eu inclua nas minhas queries? Já tentei definir os campos automac e o autoip para "sim", mas não ajuda em nada nessa questão.

Ou, se for outra coisa que não possa ser resolvida assim por fora do MK-Auth, há alguma forma de alterar o IP e o MAC de todos clientes para aqueles valores que aparecem do lado direito do campo (que imagino serem provenientes da tabela radacct), de forma que a configuração do lease funcione adequadamente no próximo login do cliente?

Desde já agradeço-lhe.

Para adicionar comentários, você deve ser membro de MK-AUTH.

Join MK-AUTH

Enviar-me um email quando as pessoas responderem –

Respostas

  • mkradius.sis_cliente é o cadastro do assinante. Essa tabela é usada para popular mkradius.radcheck que é a que o FreeRADIUS consulta quando o cliente RADIUS do Mikrotik pede autorização para o assinante. Reparar o(s) cliente(s) depois de suas alterações deve resolver seu problema.

  • A tabela mkradius.radacct armazena apenas a auditoria do servidor RADIUS. Não tem a ver com autorização nem parâmetros de configuração.

  • Obrigado, Marco, mas já tentei e reparar não resolve.

    O único caso em que funciona é alterar cliente por cliente no MK-Auth e repará-los individualmente (parece que se reparar todos também não funciona, pelo que testaram aqui). Claro que essa não é uma opção viável.

    Marco de Freitas disse:

    mkradius.sis_cliente é o cadastro do assinante. Essa tabela é usada para popular mkradius.radcheck que é a que o FreeRADIUS consulta quando o cliente RADIUS do Mikrotik pede autorização para o assinante. Reparar o(s) cliente(s) depois de suas alterações deve resolver seu problema.

  • Talvez você consiga com a API. A documentação é quase inexistente.

    Tiago de Souza disse:

    Obrigado, Marco, mas já tentei e reparar não resolve.

    O único caso em que funciona é alterar cliente por cliente no MK-Auth e repará-los individualmente (parece que se reparar todos também não funciona, pelo que testaram aqui). Claro que essa não é uma opção viável.

  • Eu realmente prefiro evitar as APIs. São simples de usar e uma solução fácil, mas não gosto da ideia de um roteador solicitando configurações por HTTP de tempos em tempo, ainda mais porque os scripts da API do MK-Auth são muito ineficientes: ao invés de apenas apagarem e reinserirem o que houve de alteração desde a última consulta pela API (olha a dica para implementação aí, Pedro, tipo um diff!), - que pode, inclusive, ser nada - eles fazem é apagar e recadastrar tudo de novo quando é executado. Até uso a API para página de aviso, mas apenas porque a quantidade de valores é pequena. A outra opção, onde o MK-Auth insere por FTP o arquivo .rsc para a RB executar também não é interessante por causa da mesma questão: apaga tudo e cadastra de novo desnecessariamente.

    Gostaria mesmo é de resolver na causa essa questão do MK-Auth não inserir o lease durante o login quando o IP e MAC foram definidos direto no banco de dados (e atributos Calling-Station-ID e Framed-IP-Address removidos nas tabelas radcheck e radreply), mesmo se fizer o reparo dos clientes. Parece ter um bug aí.

    Marco de Freitas disse:

    Talvez você consiga com a API. A documentação é quase inexistente.

    Tiago de Souza disse:

    Obrigado, Marco, mas já tentei e reparar não resolve.

    O único caso em que funciona é alterar cliente por cliente no MK-Auth e repará-los individualmente (parece que se reparar todos também não funciona, pelo que testaram aqui). Claro que essa não é uma opção viável.

  • não é parâmetro Tiago, é enviado por SSH pelo sistema e o autoip e automac vem da radacct amigo...

  • Sim, foi o que eu disse, percebi que o IP e MAC vêm da radacct e sei que é por SSH. O parâmetro ao qual me referi seria algo do MK-Auth que ele talvez usasse para saber se deveria adicionar o lease na RB quando o cliente fizesse o próximo login, e isso explicaria o porquê que alterar pelo banco de dados tem esse comportamento (lease não é adicionado): esse parâmetro não seria configurado.

    A situação é que se eu configuro o IP e MAC do cliente por dentro do MK-Auth, na aba Conexão, basta salvar e desconectar o usuário no Hotspot que quando ele reconecta o MK-Auth geralmente (às vezes tem que reparar) já adiciona o lease estático automaticamente.

    No entanto, se configuro o IP e MAC pelo banco de dados, pode desconectar o cliente, reparar ele, mudar autoip e automac para sim ou não, fazer oferenda e o que for, o MK-Auth NUNCA adiciona o lease estático, nem quando o cliente faz login, nem algum tempo depois.

    Agora eu já não preciso disso, já tornei os leases nas RBs estáticos manualmente mesmo, mas teria sido bom se tivessem sido adicionados pelo MK-Auth de forma automática.

    Além disso, tenho notado que nem mesmo para cliente novo o MK-Auth envia o lease. O mk-bot configura o IP e MAC lá no MK-Auth certinho, mas lease na RB jamais chega, mesmo se desconectar o cliente. Parece que ele funciona quando quer, esse sistema deve ter humor, kkkkk.

    Obs.: usuário/senha e chaves SSH devidamente configurados e funcionando no "Teste SSH".

    Pedro Filho disse:

    não é parâmetro Tiago, é enviado por SSH pelo sistema e o autoip e automac vem da radacct amigo...

This reply was deleted.