Radacct Reused ?

Tue May 7 17:34:02 CEST 2019

Hi Alan,

Is seems to work fine on my system the only question is use acctauthentic column that I don't use or another one better to identify acctuniqueid updated to be "safe".

I cant find every column what is used for to choose the best.

Thanks,

-----Mensaje original-----
De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com at lists.freeradius.org> En nombre de Oscar
Enviado el: domingo, 5 de mayo de 2019 16:12
Para: 'FreeRadius users mailing list' <freeradius-users at lists.freeradius.org>
Asunto: RE: Radacct Reused ?

Hi,

While I push vendor to fix the NAS i need to do a custom fix that I would like to share with anyone to try to do it as strong as possible and awful can be used by anyone else.

Short resume of the problem: 
	We don't have guaranty that the acctuniqueid from radacct would be always unique due to the low quality from the acctsessionid coming from NAS vendor on my case Mikrotik.
	Then we get reused old radacct rows (sessions) because new sessions come with same values from the past and that makes that we update old sessions.

Solution:
	After testing different options and do some mistakes I would do a daily cron job that update acctuniqueid with a different id (new md5) from all rows with acctstarttime from the day before and acctstoptime not null.
	Also, to identify the rows that has been updated with the new md5 I would use a column not used on my radacct. It that case I would use acctauthentic to store '1' that would mean the row is safe 
	** It is ok to use acctauthentic column ?

	Creating new acctuniqueid I would use: md5(concat(username,acctsessionid,framedipaddress,acctuniqueid,UNIX_TIMESTAMP(acctupdatetime),UNIX_TIMESTAMP(acctstoptime)))

	Query to update every day (datetime update according)
		update radius.radacct set acctauthentic='1', acctuniqueid=md5(concat(username,acctsessionid,framedipaddress,acctuniqueid,UNIX_TIMESTAMP(acctupdatetime),UNIX_TIMESTAMP(acctstoptime)))
			where acctstarttime between '2016-09-22 00:00:00' and '2016-09-22 23:59:59' and acctstoptime is not null and acctauthentic<>'1' ;

Until now is all I have and have tested successfully.

Any improvement will be welcome.

Will share on this threat the end code I will use: new daily job and stale session job updated.

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:55
Para: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Asunto: Re: Radacct Reused ?

On May 3, 2019, at 11:46 AM, Oscar <oscar at jofre.com> wrote:
> I do not know whether to laugh or cry :)

  That's because of bad vendors.

> Can I share your answer to mikrotik ?

  Sure.  It's a public response.

> 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.

  Yup.

  All Mikrotik has to do to fix this is to update their Acct-Session-Id to include the 32-bit Unix time of when the session started.  They *already* track this information in the user session.

  It's likely a 3-line patch.

  We can't do a similar work around in FreeRADIUS.  If we did, it would look like this:

* on every accounting packet, query the accounting table for existing / matching sessions

* if an existing session is found, AND the current packet is MAYBE not matching (due to Acct-Session-Time), THEN close the old session and create a new one

  BUT we can't do this, because UDP packets can get lost.  Accounting packets can also be delayed for hours.  So we have no idea if the "new" packet is really new, or is just a delayed "old" packet.  So this fix won't work.

  The general poor nature of the RADIUS protocol prevents us from working around stupid vendors.  Since we can't change the RADIUS protocol, we're left with bitching at the vendors.

  The only way to fix this issue permanently is for the NAS vendor to update their equipment so that it isn't crap.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html