It would appear that the MikroTiK SessionID for RADIUS authentication gets reset on a reboot and therefore cannot be considered a unique identifier within a single device. Coupled with the fact that the SessionID start value doesn’t appear to be unique across different routers, you can also get colliding session IDs for completely different routers. This seems to cause problems occasionally with our RADIUS database generating duplicate records. The underlying cause is due to network glitches causing acknowledgement packets not be received by the MikroTik router. As the Router doesn’t know the packet has actually reached the database, it tries again and under some circumstances causes a duplicate record rather than an update to the existing record.
RADIUS also generates its own “AcctUniqueID”, however this isn’t actually globally unique either!! By default it’s derived from the MikroTik session ID and some other elements, but as there is no guarantee of uniqueness in the sub elements, the overall ID cannot be guaranteed globally unique. It is compounded by the fact that the RADIUS “unique” ID is an MD5 hash. Unfortunately it is possible (although the probability is small) for duplicate MD5 hashes to be generated from completely different data!
There are a number of timing values in the MikroTik and RADIUS server which I have tuned as best as I can, but cannot eliminate the issues entirely. The problem is that the values at the server end are global and thus have to be a compromise. We have significant variation in the latency on our site connections due to some being Satellite or on oversubscribed xDSL DSLAMs. It is hard to find values which work in all scenarios.
It would be great if MikroTik could make SessionIDs universally unique, i.e. use a number of values unique to a specific router to generate a starting point and keep the SessionID stored in NVRAM so that it is recoverable on a reboot. The only remaining issue would be if the Router is replaced at some time, then unless there is a method of manually entering a SessionID start value, you would likely again end up with duplicates.
I’m now looking at using the RADIUS Location ID field (RADIUS WISPr-Location-ID) to pass back a value to the server which can be guaranteed globally unique. It will contain a unique RouterID, plus a value that is incremented by a script each time the router reboots. This value when concatenated with the SessionID at the server, should ensure a globally unique SessionID which can then be used in the database with an index on SessionID with unique constraint.
I would be interested to know whether other people suffer from duplicate records in their RADIUS database and what steps, if any, they’ve taken to eliminate or at least mitigate these.
4 years later and this is still an issue. Can anyone from MikroTik provide a response on this? When using 1,000s of MikroTik routers as HotSpot gateways and a RADIUS server, this becomes a really big problem.
Yes. This is a problem. I think time should be used to ensure the uniqueness of the SessionID. A RADIUS packets contains TimeStamp but it have the second problem. Time Stamp can be different for repeated accounting packet. So one of problems must be solved in RouterOS (and better both). I have not tested the latest version but the problem with SessionID exists in v6.36
UserName-AcctSessionId-NASIPAddress is a good candidate for SQL unique key but it can’t be used now. And I can’t add AcctStopTime(i.e. TimeStamp) because it can be different for one session:
The problem can be solved by using RADIUS “Class” attribute if “Class” isn’t used for anymore. “Class” can be return in “Access-Accept” and can contains start time of session for example. Unique key will be “UserName-AcctSessionId-NASIPAddress-Class” at this case. However, “Class” can be used for other purposes, so this solution is limited.
For example, one implementation uses a string with an 8-digit
upper case hexadecimal number, the first two digits increment on
each reboot (wrapping every 256 reboots) and the next 6 digits
counting from 0 for the first person logging in after a reboot up
to 2^24-1, about 16 million.
But I have 6 duplicates since 2018-01-10 (!) on one NAS:
select count(*) as dup, AcctSessionId, UserName, NASIPAddress from radacct group by AcctSessionId, UserName, NASIPAddress having dup > 1;
