[Bug] User Manager v7.23.1: Ghost/Stale Sessions (active=yes) with Local NAS - Regression!

RouterOS The User Manager
1

Hi everyone,

I am experiencing a persistent and frustrating issue with User Manager on RouterOS v7.23.1, where disconnected users leave behind "ghost" or stale sessions.

Important Note: This seems to be a regression bug. I did not experience this issue in earlier v7 releases (e.g., around v7.18), where session terminations were handled perfectly under the exact same configuration.

As you can see in the attached screenshot, the session has a frozen uptime (e.g., 00:35:00), the Ended field is completely blank, and UM still considers the session as active=yes. This causes "simultaneous session limit" errors for users trying to reconnect.

Here is my environment and setup:

  • RouterOS Version: v7.23.1 (Bug is present here, wasn't in ~v7.18)

  • Topology: Both NAS and User Manager are running on the SAME local router.

  • Radius Address: Configured using the loopback address (127.0.0.1).

  • Interim-Update: Initially set to 1 minute (later changed to 3-5 mins for testing).

  • Keepalive Timeout: 30 seconds.

My Observations: Since both the NAS and RADIUS server are on the same physical machine and communicating via loopback, there is absolutely no physical network link, switch, or cable where UDP Accounting-Stop packets could get dropped.

Because of this regression, I strongly suspect this is an internal database I/O issue or a database lock within the newer User Manager builds. When the router tries to write the Accounting-Stop packet while the UM database is simultaneously busy writing Interim-Updates for other users, the packet seems to be silently dropped internally, leaving the session frozen as active forever.

Has anyone else noticed this regression with local NAS setups in the recent v7.2x releases? Is MikroTik aware of this database lock/stale session bug?

Thanks in advance for any insights!

11
11641×437 8.63 KB

2

To help debugging, you can add logging topics for manager and radius:

/system logging
add topics=manager
add topics=radius

Did you enable the RADIUS Incoming - Accept setting?

/radius incoming
set accept=yes

With that, when the "simultaneous session limit" situation happens, User Manager will send CoA Disconnect-Requests that the local NAS will be able to respond to.

3

Thanks for the suggestion!

I actually already have /radius incoming set accept=yes enabled in my configuration. Unfortunately, the issue still persists, and the ghost sessions remain stuck as active=yes in the database.

4

Could you verify with the log whether the expected messages are sent and received by the two sides. If there are to much output, add !packet to the lines with the radius topic.

5 
Jun/26/2026 11:28:47 manager,debug >>> rx Accounting-Request from [127.0.0.1]:43964, id: 14
Jun/26/2026 11:28:47 manager,debug <<< tx Accounting-Response to [127.0.0.1]:43964, id: 14
Jun/26/2026 11:28:53 manager,debug >>> rx Access-Request from [127.0.0.1]:47327, id: 15
Jun/26/2026 11:28:53 manager,debug <<< tx Access-Accept to [127.0.0.1]:47327, id: 15
Jun/26/2026 11:28:53 manager,debug >>> rx Accounting-Request from [127.0.0.1]:40039, id: 16
Jun/26/2026 11:28:53 manager,debug <<< tx Accounting-Response to [127.0.0.1]:40039, id: 16
Jun/26/2026 11:29:07 manager,debug >>> rx Accounting-Request from [127.0.0.1]:54995, id: 17
Jun/26/2026 11:29:07 manager,debug <<< tx Accounting-Response to [127.0.0.1]:54995, id: 17
Jun/26/2026 11:29:26 manager,debug >>> rx Accounting-Request from [127.0.0.1]:41228, id: 18
Jun/26/2026 11:29:26 manager,debug <<< tx Accounting-Response to [127.0.0.1]:41228, id: 18
Jun/26/2026 11:29:28 manager,debug >>> rx Accounting-Request from [127.0.0.1]:42166, id: 19
Jun/26/2026 11:29:28 manager,debug <<< tx Accounting-Response to [127.0.0.1]:42166, id: 19
Jun/26/2026 11:29:36 manager,debug >>> rx Accounting-Request from [127.0.0.1]:40427, id: 20
Jun/26/2026 11:29:36 manager,debug <<< tx Accounting-Response to [127.0.0.1]:40427, id: 20
Jun/26/2026 11:29:44 manager,debug >>> rx Accounting-Request from [127.0.0.1]:44890, id: 21
Jun/26/2026 11:29:44 manager,debug Now user ****** has active session count: 0
Jun/26/2026 11:29:44 manager,debug <<< tx Accounting-Response to [127.0.0.1]:44890, id: 21
Jun/26/2026 11:29:47 manager,debug >>> rx Accounting-Request from [127.0.0.1]:53937, id: 22
Jun/26/2026 11:29:47 manager,debug <<< tx Accounting-Response to [127.0.0.1]:53937, id: 22
Jun/26/2026 11:30:07 manager,debug >>> rx Accounting-Request from [127.0.0.1]:39363, id: 23
Jun/26/2026 11:30:07 manager,debug <<< tx Accounting-Response to [127.0.0.1]:39363, id: 23
Jun/26/2026 11:30:11 manager,debug >>> rx Access-Request from [127.0.0.1]:56323, id: 24
Jun/26/2026 11:30:11 manager,debug <<< tx Access-Accept to [127.0.0.1]:56323, id: 24
Jun/26/2026 11:30:11 manager,debug >>> rx Accounting-Request from [127.0.0.1]:58195, id: 25
Jun/26/2026 11:30:11 manager,debug <<< tx Accounting-Response to [127.0.0.1]:58195, id: 25
Jun/26/2026 11:30:26 manager,debug >>> rx Accounting-Request from [127.0.0.1]:34878, id: 26
Jun/26/2026 11:30:26 manager,debug <<< tx Accounting-Response to [127.0.0.1]:34878, id: 26
Jun/26/2026 11:30:28 manager,debug >>> rx Accounting-Request from [127.0.0.1]:52073, id: 27
Jun/26/2026 11:30:28 manager,debug <<< tx Accounting-Response to [127.0.0.1]:52073, id: 27
Jun/26/2026 11:30:32 manager,debug >>> rx Accounting-Request from [127.0.0.1]:44109, id: 28
Jun/26/2026 11:30:32 manager,debug Now user ***** has active session count: 0
Jun/26/2026 11:30:32 manager,debug <<< tx Accounting-Response to [127.0.0.1]:44109, id: 28
Jun/26/2026 11:30:36 manager,debug >>> rx Accounting-Request from [127.0.0.1]:38248, id: 29
Jun/26/2026 11:30:36 manager,debug <<< tx Accounting-Response to [127.0.0.1]:38248, id: 29
Jun/26/2026 11:30:42 manager,debug >>> rx Accounting-Request from [127.0.0.1]:45618, id: 30
Jun/26/2026 11:30:42 manager,debug Now user **** has active session count: 0
Jun/26/2026 11:30:42 manager,debug <<< tx Accounting-Response to [127.0.0.1]:45618, id: 30
Jun/26/2026 11:30:47 manager,debug >>> rx Accounting-Request from [127.0.0.1]:46719, id: 31
Jun/26/2026 11:30:47 manager,debug <<< tx Accounting-Response to [127.0.0.1]:46719, id: 31
Jun/26/2026 11:31:26 manager,debug >>> rx Accounting-Request from [127.0.0.1]:56407, id: 32
Jun/26/2026 11:31:26 manager,debug <<< tx Accounting-Response to [127.0.0.1]:56407, id: 32
Jun/26/2026 11:31:28 manager,debug >>> rx Accounting-Request from [127.0.0.1]:50769, id: 33
Jun/26/2026 11:31:28 manager,debug <<< tx Accounting-Response to [127.0.0.1]:50769, id: 33
Jun/26/2026 11:31:31 manager,debug >>> rx Access-Request from [127.0.0.1]:39174, id: 34
Jun/26/2026 11:31:31 manager,debug <<< tx Access-Accept to [127.0.0.1]:39174, id: 34
Jun/26/2026 11:31:31 manager,debug >>> rx Accounting-Request from [127.0.0.1]:43905, id: 35
Jun/26/2026 11:31:31 manager,debug <<< tx Accounting-Response to [127.0.0.1]:43905, id: 35
Jun/26/2026 11:31:34 manager,debug >>> rx Access-Request from [127.0.0.1]:54868, id: 36
Jun/26/2026 11:31:34 manager,debug <<< tx Access-Accept to [127.0.0.1]:54868, id: 36
Jun/26/2026 11:31:34 manager,debug >>> rx Accounting-Request from [127.0.0.1]:50169, id: 37
Jun/26/2026 11:31:34 manager,debug <<< tx Accounting-Response to [127.0.0.1]:50169, id: 37
Jun/26/2026 11:31:36 manager,debug >>> rx Accounting-Request from [127.0.0.1]:58777, id: 38
Jun/26/2026 11:31:36 manager,debug <<< tx Accounting-Response to [127.0.0.1]:58777, id: 38