Boa tarde Pedro

hoje decidimos subir uma vmware para testar a versão 22.03 uma vez que temos em producão ainda a versão 21.06..  mas tentando buscar mais segurança e menos vulnerabilidades disponiveis para as versões do php5xx utilizado nas versões 20xx e 21.xx  decidimos subir uma máquina até a versão 21.06 que temos em producão.. em seguida fizemos um backup da máquina de producão e jogamos na máquina vm de teste.. até aqui tudo bem demorou um pouco pois o backup diário é de 820MB já.. pois temos 3 pops com cgnat rodando direto pelo mk-auth e logando toda a comunicacão já tem mais de 1 ano..

Conseguimos reiniciar a máquina e rodamos o update para a versão 22.01 e depois reiniciamos novamente e rodamos o update para a versão 22.03 ..

e colocamos a vm temporariamente em producão para autenticar os clientes. depois de uns 30 minutos comecamos a relatar alguns clientes conectando nos POPs concentradores com ip 0.0.0.0  ou seja o freeradius por algum motivo não está entregando o IP do pool do CGNAT aos usuários permitidos.. tentamos aumentar o timeout no radius servidor no mikrotik para 3000ms onde normalmente rodamos entre 300ms a 600ms dependendo do POP.. o mesmo continuou..

rodei o restart do freeradius -X via terminal para logar a comunicacão e comecamos a verificar muitas falhas no sqli.. solicitando para aumentar o "spare"

segue o log.. não sei se mais alguém está tendo este problema o que relatei é que o freeradius comeca a dar timeout-response no mikrotik e os clientes alguns autenticam com ip 0.0.0.0 e outros o radius já rejeita.. semelhante aos clientes bloqueados.

1-

(920) sql: Using query template 'query'
rlm_sql (sql): 0 of 0 connections in use. You may need to increase "spare"
rlm_sql (sql): Last connection attempt failed, waiting 30 seconds before retrying
(920) [sql] = fail
(920) } # Post-Auth-Type REJECT = fail
(920) Rejected in post-auth: [flaviasilva/<via Auth-Type = mschap>] (from client Clientes - POP1 port 16247703 cli 28:3B:82:23:BA:6E)
(920) Delaying response for 3.000000 seconds
(921) Received Access-Request Id 146 from 10.5.5.200:45444 to 10.25.25.200:1812 length 233
(921) Service-Type = Framed-User
(921) Framed-Protocol = PPP
(921) NAS-Port = 16247698
(921) NAS-Port-Type = Ethernet
(921) User-Name = "danubiopereira"
(921) Calling-Station-Id = "0C:B6:D2:8F:5E:A1"
(921) Called-Station-Id = "PPPOE-FIBRA"
(921) NAS-Port-Id = "VLAN-1024-PPPoE-Server"
(921) Acct-Session-Id = "81979754"
(921) MS-CHAP-Challenge = 0xeb3c595faf7748f8d76b5eb26645d0b0
(921) MS-CHAP2-Response = 0x01007443fe5a89e6183f1f1f37f982ce33240000000000000000552251ead95b118670f752e85248aa305894af33bca56054
(921) NAS-Identifier = "R0UT3R-NSK4"
(921) NAS-IP-Address = 10.5.5.200
(921) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default
(921) authorize {
(921) [preprocess] = ok
(921) [chap] = noop
(921) mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap'
(921) [mschap] = ok
(921) [digest] = noop
(921) suffix: Checking for suffix after "@"
(921) suffix: No '@' in User-Name = "danubiopereira", looking up realm NULL
(921) suffix: No such realm "NULL"
(921) [suffix] = noop
(921) eap: No EAP-Message, not doing EAP
(921) [eap] = noop
(921) sql: EXPAND %{User-Name}
(921) sql: --> danubiopereira
(921) sql: SQL-User-Name set to 'danubiopereira'
rlm_sql (sql): 0 of 0 connections in use. You may need to increase "spare"
rlm_sql (sql): Last connection attempt failed, waiting 30 seconds before retrying
(921) [sql] = fail
(921) } # authorize = fail
(921) Invalid user: [danubiopereira/<via Auth-Type = mschap>] (from client Clientes - POP1 port 16247698 cli 0C:B6:D2:8F:5E:A1)
(921) Using Post-Auth-Type Reject
(921) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(921) Post-Auth-Type REJECT {
(921) sql: EXPAND .query
(921) sql: --> .query
(921) sql: Using query template 'query'
rlm_sql (sql): 0 of 0 connections in use. You may need to increase "spare"
rlm_sql (sql): Last connection attempt failed, waiting 30 seconds before retrying
(921) [sql] = fail
(921) } # Post-Auth-Type REJECT = fail
(921) Rejected in post-auth: [danubiopereira/<via Auth-Type = mschap>] (from client Clientes - POP1 port 16247698 cli 0C:B6:D2:8F:5E:A1)
(921) Delaying response for 3.000000 seconds

2- SMS Gateway da SMSNET estava com usuário login alterado para qqq após atualizacão

3- GERENCIANET retorno não está funcionando, normalmente MK-BOT atualiza os pagamentos no mk-auth de madrugada e faz as baixas nos boletos, hoje não recebeu nenhuma comunicacão e não deu baixa, apesar de constar boletos pagos no gerencianet.  quando clicamos no callback no fortunus api. ele dá ok toda a comunicacão, provavelmente alguma crontab, não está funcionando?

4- O BACKUP na versão 22.03 também não funciona.. pegamos o backup de 800megas efetuado na madrugada , subimos outra VM e atualizamos de novo até a versão 22.03  em seguida subimos o backup e ele foi carregado com sucesso, conseguimos ver o backup em /opt/bckp.  Quando clicamos em carregar para o sistema , notamos que ele gera outro arquivo backup.bz2  dentro da pasta backup e quando chega em 1.3gb ele para e não faz mais nada , e nas versões anteriores ele gerava mais uns arquivos radacct. um banco de dados de quase 12gigas tar.sql..  e agora não gera.. porém a mensagem de backup gerado com sucesso aparece no print da tela do menu do mk-auth..   resumindo está com uma série de problemas e não carrega o backup, reiniciamso a vmware de teste e ao acessar novamente mostra a mesma quantidad ede clientes, titutlos etc.. do backup anterior na versão anterior feito a 2 dias atrás.