Falha recorrente de autenticação PPPoE resolvida (temporariamente) apenas com

Estou enfrentando um problema recorrente onde novas autenticações PPPoE deixam de funcionar até que eu execute a opção Reparar Usuários.

Sintoma

Clientes já conectados continuam navegando normalmente.
As sessões PPPoE existentes não caem.
Apenas novas autenticações falham.
Se um cliente desconectar por qualquer motivo, não consegue reconectar.
Após executar Reparar Usuários, todos os clientes voltam a autenticar normalmente.

Ambiente

MK-AUTH 26.01 :: TUX 6.6
FreeRADIUS 3.0.17
MariaDB 10.3

O que já verifiquei

FreeRADIUS permanece em execução durante a falha.
Banco de dados operacional e sem locks aparentes.
Usuários possuem normalmente o atributo Cleartext-Password na tabela radcheck.
Não encontrei erros de conexão SQL entre FreeRADIUS e MariaDB.

Logs

Durante a falha aparecem diversos registros semelhantes a:

mschap: FAILED: No NT/LM-Password. Cannot perform authentication

Comportamento observado

O problema já ocorreu em dias diferentes, geralmente pela manhã, e sempre foi resolvido imediatamente após executar Reparar Usuários.

Agradeço qualquer orientação.

Realizei o teste conforme solicitado.

A opção Auto Desconecta já estava habilitada antes mesmo de qualquer alteração, e todos os clientes já estavam configurados para permitir apenas uma sessão simultânea.

Para o teste, habilitei a opção Simultâneos no cadastro de apenas um cliente específico e salvei. Em seguida, acessei Provedor > Controle de Ramais. Como a opção Auto Desconecta já estava habilitada, apenas a desmarquei, salvei, depois a marquei novamente e salvei outra vez, retornando exatamente ao estado original.

Imediatamente após essas alterações, o cliente utilizado no teste e diversos outros clientes que não conseguiam autenticar voltaram a conectar normalmente, sem que fosse necessário executar a opção Reparar Usuários.

Isso indica que o problema não está diretamente relacionado ao estado dessas configurações, mas sim ao fato de que o simples ato de salvar as configurações do Controle de Ramais parece executar alguma rotina interna que restabelece o processo de autenticação PPPoE.

Gostaria de saber qual rotina é executada ao salvar essas configurações, pois o comportamento observado é muito semelhante ao da opção Reparar Usuários.

Respostas

🌎 Elton Pereira ✅ Suporte / Addons /API Junho 25, 2026 15:04

Lembrando que quando ativa o simuntanio é necessario reparar os clientes.
🌎 Ajuda sistema MK-AUTH Junho 25, 2026 11:37

Bom dia prezado(a),

Acompanhe para ver se vai ocorrer novamete com o cliente que você habilitou "simultaneos" no cadastro.

O sistema faz um refresh para que as novas configurações subam depois de salvar uma alteração feita no ramal.

Qualquer dúvida, estamos à disposição.
Atenciosamente,
Atendimento de suporte ao sistema
___________ MK-AUTH __________
Samuel Silva Sardinha Junho 25, 2026 9:49

Status do Mysql e do Freeradius. O Freeradius reiniciou e me parece que os usuarios reconectaram apenas por causa disso.

LOG anexado de antes e depois de realizar as alterações mostram, além de outras coisas, que o freeradius foi reiniciado cada vez que eu salvava as config na tela do MKAuth

freeradius.log
Samuel Silva Sardinha Junho 25, 2026 9:12

Realizei o teste conforme solicitado.

A opção Auto Desconecta já estava habilitada antes mesmo de qualquer alteração, e todos os clientes já estavam configurados para permitir apenas uma sessão simultânea.

Para o teste, habilitei a opção Simultâneos no cadastro de apenas um cliente específico e salvei. Em seguida, acessei Provedor > Controle de Ramais. Como a opção Auto Desconecta já estava habilitada, apenas a desmarquei, salvei, depois a marquei novamente e salvei outra vez, retornando exatamente ao estado original.

Imediatamente após essas alterações, o cliente utilizado no teste e diversos outros clientes que não conseguiam autenticar voltaram a conectar normalmente, sem que fosse necessário executar a opção Reparar Usuários.

Isso indica que o problema não está diretamente relacionado ao estado dessas configurações, mas sim ao fato de que o simples ato de salvar as configurações do Controle de Ramais parece executar alguma rotina interna que restabelece o processo de autenticação PPPoE.

Gostaria de saber qual rotina é executada ao salvar essas configurações, pois o comportamento observado é muito semelhante ao da opção Reparar Usuários.
🌎 Elton Pereira ✅ Suporte / Addons /API Junho 25, 2026 8:42

@Samuel Silva Sardinha bom dia, comentario amigo, PZ Junho 24, 2026 16:24 efetua os procedimento desse comentario. é justamente um dos motivos de da o seu problema. por isso foi marcado ele. se não solucionar, recomento reistalar sistema.
Samuel Silva Sardinha Junho 25, 2026 8:34

Bom dia

Os assuntos abordados nos comentarios nao tem nada a ver com o assunto do meu post pedindo ajuda. Aqui novamente apresentou o mesmo problema. So resolve se eu reparar os usuarios, ai tenho derrubar todos os clientes para resolver alguns. Alguem consegue dar uma luz?
PZ Junho 24, 2026 17:16

Meu caso foi resolvido obrigado!
🌎 Ajuda sistema MK-AUTH Junho 24, 2026 16:58

Boa tarde PZ,

Esse tópico pode te ajudar;
https://mk-auth.com.br/forum/topics/logs-de-conexao-triplicado

Qualquer dúvida, estamos à disposição.
Atenciosamente,
Atendimento de suporte ao sistema
___________ MK-AUTH __________
PZ Junho 24, 2026 16:24

Aqui o sintoma é parecido, Clientes com conexões triplicadas...
Cliente está com simultâneo = NÂO

E no controle de ramais está com AUTO DESCONTECA marcado.

Ainda assim gera 3 a 4 conexões por usuário com mesmo ID, e permenece comencado.

O que fazer para corrigir isso?
🌎 Ajuda sistema MK-AUTH Junho 24, 2026 9:31

Bom dia prezado(a),

faça um teste habilitando a opção de 'simultaneos' no cadastros dos clientes e habilite a opção 'Auto desconecta' em Provedor > controle de ramais no botão da engrenagem, confira se as outras opções estão marcadas corretamente.

Qualquer dúvida, estamos à disposição.
Atenciosamente,
Atendimento de suporte ao sistema
___________ MK-AUTH __________

This reply was deleted.