Hi Alan,
I do not know whether to laugh or cry :)
Can I share your answer to mikrotik ?
About:
>> The only real solution here is to *remove* the entry from the accounting table when you get a stop. But you might *not* get a "stop" packet, so even that solution isn't perfect.
I think it would be the same, instead of remove the radacct row, as we have also a radacctid unique to update acctuniqueid with (acctuniqueid+radacctid) when acctstoptime (stop accounting) comes.
And of course on stale sessions the same, if stop packet doesn't come.
Thanks,
-----Mensaje original-----
De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com at lists.freeradius.org> En nombre de Alan DeKok
Enviado el: viernes, 3 de mayo de 2019 17:30
Para: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Asunto: Re: Radacct Reused ?
On May 3, 2019, at 11:10 AM, Oscar <oscar at jofre.com> wrote:
>
> I did ask to mikroitk about my problem and the Acct-Session-Id not beeign uniqe and here is their answer:
>
>>>> Hello,
>>>>
>>>> RFC does not have strict requirements for Acct-Session-Id parameter.
That is a stupid response.
The RFCs also don't have strict requirements against shooting yourself in the foot. But most people think it's a bad idea.
The reality is that any competent NAS vendor creates Acct-Session-Id values which are mostly unique. This isn't that difficult to do.
>>>>
>>>> https://tools.ietf.org/html/rfc2866#section-5.5
>>>>
>>>> In RouterOS, the first two symbols of session ID represent service (PPP, Hotspot, etc.). The next symbol is incremented on each reboot. The last group of symbols is incremented on each new session. This means, that you can not get the same ID for 1 million re-connects on the same boot for the same RADIUS type service.
What this means is that they don't actually track Acct-Session-Id for each session. Instead, they have a unique session number that they use internally. They then create the Acct-Session-Id for each packet by concatenating the various fields, including the session number.
Perhaps they should look at a calendar, and see that it's 2019. Tracking a (presumably) 32-bit number isn't much different from tracking a 16-byte *unique* value for Acct-Session-Id.
>>>> If you lose session stop message and RADIUS server does still keep the session open, but then receives another session start message, then it must be aware that stop message was lost, close old session and start a new session.
That's a stupid response.
The problem is that the RADIUS server might not *get* the session start message. Instead, it just gets the "alive" message.
So the RADIUS server can't *tell* it's a new session. It has the same User-Name, Acct-Session-ID, NAS information, etc
If the Acct-Session-ID was different, the RADIUS server *could* tell that the same user was on the same port, BUT with a different session.
Perhaps the Mikrotik guys are idiots, and are unaware that UDP packets can be lost. The RADIUS server has to deal with this situation, which means that the NAS shouldn't be lying to the RADIUS server.
>>>> In short none of the systems can maintain unique session ID forever. In most of the systems, you can generate up to 16 million unique IDs.
That's a stupid response.
It's easy to create unique Acct-Session-Id values. They do it already for creating the Request Authenticator in Access-Request packets.
And there's no need to maintain a unique session ID "forever". They just need to track it for a session, and throw the value away when the session closes.
>>>> Best regards,
i.e. "we're not going to fix our crappy product".
My $0.02 is to buy a product that works. Drop Mikrotik stuff in the garbage, as it *creates* problems.
> I'm just in the middle using both systems freeradius and mikrotik hotspot.
>
> And I'm trying to find a solution to solve the radacct resused.
The good news is that FreeRADIUS isn't stupid, and it's much more configurable than Mikrotik. So if it's at all possible, you can maybe work around it.
> I see that you also know the difficul of get a real unique id from NAS, even CISCO does something similar and the RFC define a use quite similar than mikrotik does, and tryes to create a stronger unique id freeradius does:
>
> &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}"
Yes. We do that because of stupid NAS vendors. But some are so stupid that this work-around doesn't work.
> But when there any many and many nas with the same behaver as me even this stronger unique id is not enough.
There are very few NASes with poor Acct-Session-Id behaviour. Most vendors that were bad have gotten customer complaints, and then fixed their product.
> My thought to solve this (I can't even tell recomandation) would be to update this Acct-Unique-Session-Id (acctuniqueid) once the session is closed with a concatenation of its value and for example timestamps of the acctstoptime. That way we will be really sure that this record won't be resused on the future.
> Also the ones that use a job to close the Stale sessions can update this acctuniqueid following this "rule".
The only real solution here is to *remove* the entry from the accounting table when you get a stop. But you might *not* get a "stop" packet, so even that solution isn't perfect.
> I don't want to poke the FreeRADIUS configuration I just want to make it stronger as it is trying to be using a contatenation of parameters to create a stronger uniqueid.
You only have the information that's in the RADIUS packet. If the NAS doesn't send useful information, there's nothing you can do.
There are two solutions here:
a) the Mikrotik guys stop being stupid, and fix their product
b) you throw the Mikrotik equipment in the garbage, and buy a product from a vendor who cares about their customers.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html