Hi, I've created a Trigger to save on a new table the las time a user has been stop connection (acctstoptime). So I've createad table and created this trigger: create TRIGGER UpdateStopTime AFTER UPDATE ON radacct FOR EACH ROW BEGIN INSERT into usuario_instalacion_stoptime ( select u.department as user,u.company as insta,if(r.acctstoptime is null,now(),r.acctstoptime) stoptime from radacct r,userinfo u where r.username=u.username and r.radacctid=NEW.radacctid ) ON DUPLICATE KEY UPDATE stoptime=if(NEW.acctstoptime is null,now(),NEW.acctstoptime) ; END$$ But now I'm facing that sems that radius rows from the past are beeign used on the present I mean, my radacctid is now arround 37.000.000 And I can see a user autheticated and updating a really old row: accstoptime=09-2018 and beeing update today with accstarttime=04-2019 How is that possible ? Is it correct ? Thanks,
-----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Oscar Enviado el: martes, 16 de abril de 2019 23:52 Para: 'FreeRadius users mailing list' <freeradius-users@lists.freeradius.org> Asunto: Radacct Reused ? Hi, I've created a Trigger to save on a new table the las time a user has been stop connection (acctstoptime). So I've createad table and created this trigger: create TRIGGER UpdateStopTime AFTER UPDATE ON radacct FOR EACH ROW BEGIN INSERT into usuario_instalacion_stoptime ( select u.department as user,u.company as insta,if(r.acctstoptime is null,now(),r.acctstoptime) stoptime from radacct r,userinfo u where r.username=u.username and r.radacctid=NEW.radacctid ) ON DUPLICATE KEY UPDATE stoptime=if(NEW.acctstoptime is null,now(),NEW.acctstoptime) ; END$$ But now I'm facing that sems that radius rows from the past are beeign used on the present I mean, my radacctid is now arround 37.000.000 And I can see a user autheticated and updating a really old row: accstoptime=09-2018 and beeing update today with accstarttime=04-2019 How is that possible ? Is it correct ? Thanks,
https://wiki.freeradius.org/guide/Users-Mailing-List#full-server-debug-outpu... Don't post images. Don't post the same message. We got it the first time. The default configuration works. If you want to know why your trigger is broken, go read the default queries and see what they do. i.e. you wrote code to break the server. Don't do that.
On Apr 18, 2019, at 2:51 AM, Oscar <oscar@jofre.com> wrote:
-----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Oscar Enviado el: martes, 16 de abril de 2019 23:52 Para: 'FreeRadius users mailing list' <freeradius-users@lists.freeradius.org> Asunto: Radacct Reused ?
Hi,
I've created a Trigger to save on a new table the las time a user has been stop connection (acctstoptime).
So I've createad table and created this trigger:
create TRIGGER UpdateStopTime AFTER UPDATE ON radacct
FOR EACH ROW
BEGIN
INSERT into usuario_instalacion_stoptime (
select u.department as user,u.company as insta,if(r.acctstoptime is null,now(),r.acctstoptime) stoptime
from radacct r,userinfo u where r.username=u.username and r.radacctid=NEW.radacctid
) ON DUPLICATE KEY UPDATE stoptime=if(NEW.acctstoptime is null,now(),NEW.acctstoptime) ;
END$$
But now I'm facing that sems that radius rows from the past are beeign used on the present
I mean, my radacctid is now arround 37.000.000
And I can see a user autheticated and updating a really old row: accstoptime=09-2018 and beeing update today with accstarttime=04-2019
How is that possible ?
Is it correct ?
Thanks,
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, Sorry for this: https://wiki.freeradius.org/guide/Users-Mailing-List#full-server-debug-outpu... I'm not going to do it again.
If you want to know why your trigger is broken, go read the default queries and see what they do. i.e. you wrote code to break the server. Don't do that.
I don't understand what you mean. My freeradius is on default configuration (as far as I know) version 3.0.13 My trigger only add a row on a new table. Don't modify anything from the setup or freeradius database. What I'm facing is that I have a row from an old time: radacct=24850583 acctsessionid=80a00001 acctuniqueid=6cf28675aa2c38a046d7f46f65e36e72 acctstoptime= 2018-02-24 22:02:26 And yestarday I got from freeradius an insert with same acctsessionid, acctstoptime: 20190417 19:42:18,ip-10-10-2-197,radius,172.31.27.182,46429987,224924771,QUERY,radius,'INSERT INTO radacct (acctsessionid, acctuniqueid, username, realm, nasipaddress, nasportid, nasporttype, acctstarttime, acctupdatetime, acctstoptime, acctsessiontime, acctauthentic, connectinfo_start, connectinfo_stop, acctinputoctets, acctoutputoctets, calledstationid, callingstationid, acctterminatecause, servicetype, framedprotocol, framedipaddress) VALUES (\'80a00001\', \'6cf28675aa2c38a046d7f46f65e36e72\', \'SwB_120669_ins_425_E8:11:32:E3:77:AF\', \'\', \'172.16.4.74\', \'bridge-hs\', \'Wireless-802.11\', FROM_UNIXTIME(1555530138), FROM_UNIXTIME(1555530138), NULL, \'0\', \'\', \'\', \'\', \'0\', \'0\', \'4AC704E1E050\', \'E8:11:32:E3:77:AF\', \'\', \'\', \'\', \'10.1.200.203\')',1062 This insert fails due to duplicate key. Error Code: 1062. Duplicate entry '6cf28675aa2c38a046d7f46f65e36e72' for key 'acctuniqueid' And then the updates comes: 20190417 19:42:18,ip-10-10-2-197,radius,172.31.27.182,46429987,224924772,QUERY,radius,'UPDATE radacct SET acctstarttime = FROM_UNIXTIME(1555530138), acctupdatetime = FROM_UNIXTIME(1555530138), connectinfo_start = \'\' WHERE AcctUniqueId = \'6cf28675aa2c38a046d7f46f65e36e72\'',0 Can you help me to know how is calculated the 'acctuniqueid' to see why appears duplicated ? Maybe it is important to share that the freeradius has been working on a server machine the last 2 years and we migrate to a new machine, we move from the old machine to the new all database and we update version from freeradius 3.0.10 on the old machine to 3.0.13 on the new machine. Thanks, -----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Alan DeKok Enviado el: jueves, 18 de abril de 2019 13:45 Para: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Asunto: Re: Radacct Reused ? https://wiki.freeradius.org/guide/Users-Mailing-List#full-server-debug-outpu... Don't post images. Don't post the same message. We got it the first time. The default configuration works. If you want to know why your trigger is broken, go read the default queries and see what they do. i.e. you wrote code to break the server. Don't do that.
On Apr 18, 2019, at 2:51 AM, Oscar <oscar@jofre.com> wrote:
-----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Oscar Enviado el: martes, 16 de abril de 2019 23:52 Para: 'FreeRadius users mailing list' <freeradius-users@lists.freeradius.org> Asunto: Radacct Reused ?
Hi,
I've created a Trigger to save on a new table the las time a user has been stop connection (acctstoptime).
So I've createad table and created this trigger:
create TRIGGER UpdateStopTime AFTER UPDATE ON radacct
FOR EACH ROW
BEGIN
INSERT into usuario_instalacion_stoptime (
select u.department as user,u.company as insta,if(r.acctstoptime is null,now(),r.acctstoptime) stoptime
from radacct r,userinfo u where r.username=u.username and r.radacctid=NEW.radacctid
) ON DUPLICATE KEY UPDATE stoptime=if(NEW.acctstoptime is null,now(),NEW.acctstoptime) ;
END$$
But now I'm facing that sems that radius rows from the past are beeign used on the present
I mean, my radacctid is now arround 37.000.000
And I can see a user autheticated and updating a really old row: accstoptime=09-2018 and beeing update today with accstarttime=04-2019
How is that possible ?
Is it correct ?
Thanks,
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 18, 2019, at 7:24 PM, Oscar <oscar@jofre.com> wrote:
I don't understand what you mean. My freeradius is on default configuration (as far as I know) version 3.0.13
You asked about why the information in SQL was wrong, and mentioned the added trigger. It should not be a surprise that the response is "maybe the problem is the trigger".
And yestarday I got from freeradius an insert with same acctsessionid, acctstoptime:
20190417 19:42:18,ip-10-10-2-197,radius,172.31.27.182,46429987,224924771,QUERY,radius,'INSERT INTO radacct (acctsessionid, acctuniqueid, username, realm, nasipaddress, nasportid, nasporttype, acctstarttime, acctupdatetime, acctstoptime, acctsessiontime, acctauthentic, connectinfo_start, connectinfo_stop, acctinputoctets, acctoutputoctets, calledstationid, callingstationid, acctterminatecause, servicetype, framedprotocol, framedipaddress) VALUES (\'80a00001\', \'6cf28675aa2c38a046d7f46f65e36e72\', \'SwB_120669_ins_425_E8:11:32:E3:77:AF\', \'\', \'172.16.4.74\', \'bridge-hs\', \'Wireless-802.11\', FROM_UNIXTIME(1555530138), FROM_UNIXTIME(1555530138), NULL, \'0\', \'\', \'\', \'\', \'0\', \'0\', \'4AC704E1E050\', \'E8:11:32:E3:77:AF\', \'\', \'\', \'\', \'10.1.200.203\')',1062
This insert fails due to duplicate key.
Error Code: 1062. Duplicate entry '6cf28675aa2c38a046d7f46f65e36e72' for key 'acctuniqueid'
It would have helped to say this at the start. If the trigger isn't relevant, you shouldn't have mentioned it.
And then the updates comes:
20190417 19:42:18,ip-10-10-2-197,radius,172.31.27.182,46429987,224924772,QUERY,radius,'UPDATE radacct SET acctstarttime = FROM_UNIXTIME(1555530138), acctupdatetime = FROM_UNIXTIME(1555530138), connectinfo_start = \'\' WHERE AcctUniqueId = \'6cf28675aa2c38a046d7f46f65e36e72\'',0
Can you help me to know how is calculated the 'acctuniqueid' to see why appears duplicated ?
The debug output shows you when / where it's calculated.
Maybe it is important to share that the freeradius has been working on a server machine the last 2 years and we migrate to a new machine, we move from the old machine to the new all database and we update version from freeradius 3.0.10 on the old machine to 3.0.13 on the new machine.
Why not upgrade to 3.0.19? It will fix all known problems. Alan DeKok.
Hi,
The debug output shows you when / where it's calculated.
I'm running on a production environment can't run radiusd -X. Can you help me on where it is calculated ?
Why not upgrade to 3.0.19?
When I migrate to AWS I jump from centos 7 to Amazon Linux VERSION="2" ID="amzn" ID_LIKE="centos rhel fedora" VERSION_ID="2" PRETTY_NAME="Amazon Linux 2" I did try to compile and install I think it was 3.0.17 by the time I did the migration but could not fix compile errors and I did install the repo version 3.0.13 I think still the same version on the repo. I did check logs changes from 3.0.13 to 3.0.19 and couldn't see anything from any fix about 'acctuniqueid'. Do you think the version 3.0.13 could be the problem on the reuse of 'acctuniqueid' ? Thanks -----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Alan DeKok Enviado el: viernes, 19 de abril de 2019 20:12 Para: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Asunto: Re: Radacct Reused ? On Apr 18, 2019, at 7:24 PM, Oscar <oscar@jofre.com> wrote:
I don't understand what you mean. My freeradius is on default configuration (as far as I know) version 3.0.13
You asked about why the information in SQL was wrong, and mentioned the added trigger. It should not be a surprise that the response is "maybe the problem is the trigger".
And yestarday I got from freeradius an insert with same acctsessionid, acctstoptime:
20190417 19:42:18,ip-10-10-2-197,radius,172.31.27.182,46429987,224924771,QUERY,radius,'INSERT INTO radacct (acctsessionid, acctuniqueid, username, realm, nasipaddress, nasportid, nasporttype, acctstarttime, acctupdatetime, acctstoptime, acctsessiontime, acctauthentic, connectinfo_start, connectinfo_stop, acctinputoctets, acctoutputoctets, calledstationid, callingstationid, acctterminatecause, servicetype, framedprotocol, framedipaddress) VALUES (\'80a00001\', \'6cf28675aa2c38a046d7f46f65e36e72\', \'SwB_120669_ins_425_E8:11:32:E3:77:AF\', \'\', \'172.16.4.74\', \'bridge-hs\', \'Wireless-802.11\', FROM_UNIXTIME(1555530138), FROM_UNIXTIME(1555530138), NULL, \'0\', \'\', \'\', \'\', \'0\', \'0\', \'4AC704E1E050\', \'E8:11:32:E3:77:AF\', \'\', \'\', \'\', \'10.1.200.203\')',1062
This insert fails due to duplicate key.
Error Code: 1062. Duplicate entry '6cf28675aa2c38a046d7f46f65e36e72' for key 'acctuniqueid'
It would have helped to say this at the start. If the trigger isn't relevant, you shouldn't have mentioned it.
And then the updates comes:
20190417 19:42:18,ip-10-10-2-197,radius,172.31.27.182,46429987,224924772,QUERY,radius,'UPDATE radacct SET acctstarttime = FROM_UNIXTIME(1555530138), acctupdatetime = FROM_UNIXTIME(1555530138), connectinfo_start = \'\' WHERE AcctUniqueId = \'6cf28675aa2c38a046d7f46f65e36e72\'',0
Can you help me to know how is calculated the 'acctuniqueid' to see why appears duplicated ?
The debug output shows you when / where it's calculated.
Maybe it is important to share that the freeradius has been working on a server machine the last 2 years and we migrate to a new machine, we move from the old machine to the new all database and we update version from freeradius 3.0.10 on the old machine to 3.0.13 on the new machine.
Why not upgrade to 3.0.19? It will fix all known problems. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 19, 2019, at 5:39 PM, Oscar <oscar@jofre.com> wrote:
The debug output shows you when / where it's calculated.
I'm running on a production environment can't run radiusd -X.
You can always run it on a different port. See the documentation.
Can you help me on where it is calculated ?
You *can* search the configuration files. Look for "acctuniqueid" or "Acct-Unique-Session-Id" Searching configuration files for text is a basic sysadmin skill.
Why not upgrade to 3.0.19?
When I migrate to AWS I jump from centos 7 to Amazon Linux VERSION="2" ID="amzn" ID_LIKE="centos rhel fedora" VERSION_ID="2" PRETTY_NAME="Amazon Linux 2"
I did try to compile and install I think it was 3.0.17 by the time I did the migration but could not fix compile errors and I did install the repo version 3.0.13 I think still the same version on the repo.
There are pre-built packages on my companies web site: https://networkradius.com/freeradius-packages/
I did check logs changes from 3.0.13 to 3.0.19 and couldn't see anything from any fix about 'acctuniqueid'.
Do you think the version 3.0.13 could be the problem on the reuse of 'acctuniqueid' ?
I have no idea. Alan DeKok.
Hi, I've serch and found the pice of code that I think creates the unique id update request { &Tmp-String-9 := "${policy.class_value_prefix}" } if (("%{hex:&Class}" =~ /^%{hex:&Tmp-String-9}/) && \ ("%{string:&Class}" =~ /^${policy.class_value_prefix}([0-9a-f]{32})/i)) { update request { &Acct-Unique-Session-Id := "%{md5:%{1},%{Acct-Session-ID}}" } } # # Not All devices respect RFC 2865 when dealing with # the class attribute, so be prepared to use the # older style of hashing scheme if a class attribute # is not included # else { update request { &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}" } } } I'm trying to understand why acctuniqueid=6cf28675aa2c38a046d7f46f65e36e72 has been created again and can't follow this code. Where and what is the class I gess {%1} ? hex:&Class ? string:&Class ? I think if in my case we go throw: &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}" Then unique id can be reused because user-name and rest of values can be the same. Where comes the Acct-Session-ID ? Sorry for too many questons ... but try to figure out how it works. Thanks, Thanks, -----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Alan DeKok Enviado el: viernes, 19 de abril de 2019 23:50 Para: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Asunto: Re: Radacct Reused ? On Apr 19, 2019, at 5:39 PM, Oscar <oscar@jofre.com> wrote:
The debug output shows you when / where it's calculated.
I'm running on a production environment can't run radiusd -X.
You can always run it on a different port. See the documentation.
Can you help me on where it is calculated ?
You *can* search the configuration files. Look for "acctuniqueid" or "Acct-Unique-Session-Id" Searching configuration files for text is a basic sysadmin skill.
Why not upgrade to 3.0.19?
When I migrate to AWS I jump from centos 7 to Amazon Linux VERSION="2" ID="amzn" ID_LIKE="centos rhel fedora" VERSION_ID="2" PRETTY_NAME="Amazon Linux 2"
I did try to compile and install I think it was 3.0.17 by the time I did the migration but could not fix compile errors and I did install the repo version 3.0.13 I think still the same version on the repo.
There are pre-built packages on my companies web site: https://networkradius.com/freeradius-packages/
I did check logs changes from 3.0.13 to 3.0.19 and couldn't see anything from any fix about 'acctuniqueid'.
Do you think the version 3.0.13 could be the problem on the reuse of 'acctuniqueid' ?
I have no idea. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 19, 2019, at 6:40 PM, Oscar <oscar@jofre.com> wrote:
I've serch and found the pice of code that I think creates the unique id
Yes.
I'm trying to understand why acctuniqueid=6cf28675aa2c38a046d7f46f65e36e72 has been created again
Because all of the values used to create it are the same.
and can't follow this code.
Where and what is the class I gess {%1} ? hex:&Class ? string:&Class ?
See "man unlang".
I think if in my case we go throw: &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}"
Then unique id can be reused because user-name and rest of values can be the same.
Yes.
Where comes the Acct-Session-ID ?
The NAS sends it. If you read the debug output, you will see this.
Sorry for too many questons ... but try to figure out how it works.
The short answer for the problem here is that the NAS is re-using values for sessions. It's not supposed to do that. The Acct-Session-Id is *supposed* to be mostly unique. If the NAS is this bad, then no amount of poking the FR config will fix it. There is literally nothing you can do to stop the problem of re-used sessions. You have to get a NAS which implements RADIUS properly. i.e. one that isn't garbage. Alan DeKok.
Hi, About: # If we have a class attribute in the format # 'auth_id:[0-9a-f]{32}' it'll have a local value # (defined by insert_acct_class), this ensures # uniqueness and suitability. # # We could just use the Class attribute as # Acct-Unique-Session-Id, but this may cause problems # with NAS that carry Class values across between # multiple linked sessions. So we rehash class with # Acct-Session-ID to provide a truely unique session # identifier. # # Using a Class/Session-ID combination is more robust # than using elements in the Accounting-Request, # which may be subject to change, such as # NAS-IP-Address, Client-IP-Address and # NAS-Port-ID/NAS-Port. # # This policy should ensure that session data is not # affected if NAS IP addresses change, or the client # roams to a different 'port' whilst maintaining its # initial authentication session (Common in a # wireless environment). Is Class an attribute that should come from the NAS ? I'm using mikroitk as a NAS and I think/hope is not garbage. This is what it is sending as accounting 22:14:40 radius,debug sending 3f:41a8 to 18.194.84.153:1813 22:14:40 radius,debug,packet sending Accounting-Request with id 14 to 18.194.84.153:1813 22:14:40 radius,debug,packet Signature = 0x72ab4a619fdecb98eeaefe7322abe9fe 22:14:40 radius,debug,packet Acct-Status-Type = 3 22:14:40 radius,debug,packet NAS-Port-Type = 19 22:14:40 radius,debug,packet Calling-Station-Id = "30:07:4D:50:64:AA" 22:14:40 radius,debug,packet Called-Station-Id = "8D0008D14A5D" 22:14:40 radius,debug,packet NAS-Port-Id = "bridge-hs" 22:14:40 radius,debug,packet User-Name = "SwB_3094873_ins_6971_30:07:4D:50:64:AA" 22:14:40 radius,debug,packet NAS-Port = 2148532224 22:14:40 radius,debug,packet Acct-Session-Id = "80100000" 22:14:40 radius,debug,packet Framed-IP-Address = 10.1.200.245 22:14:40 radius,debug,packet MT-Host-IP = 10.1.200.245 22:14:40 radius,debug,packet Event-Timestamp = 1555877680 22:14:40 radius,debug,packet Acct-Input-Octets = 381336 22:14:40 radius,debug,packet Acct-Output-Octets = 2678031 22:14:40 radius,debug,packet Acct-Input-Gigawords = 0 22:14:40 radius,debug,packet Acct-Output-Gigawords = 0 22:14:40 radius,debug,packet Acct-Input-Packets = 2751 22:14:40 radius,debug,packet Acct-Output-Packets = 3153 22:14:40 radius,debug,packet Acct-Session-Time = 3959 22:14:40 radius,debug,packet NAS-Identifier = "SERVER" 22:14:40 radius,debug,packet Acct-Delay-Time = 0 22:14:40 radius,debug,packet NAS-IP-Address = 172.16.8.118 22:14:40 radius,debug,packet received Accounting-Response with id 14 from 18.194.84.153:1813 22:14:40 radius,debug,packet Signature = 0x472ef1a6d674428935cc4b732b2f8363 22:14:40 radius,debug received reply for 3f:41a8 22:14:40 radius,debug request 3f:41a8 processed 22:15:34 system,info,account user admin logged in from 192.168.0.158 via telnet Definitly I think Acct-Session-Id is not unique id but as I've seen on mikrotik manual radius manual: https://wiki.mikrotik.com/wiki/Manual:RADIUS_Client Access-Request NAS-Identifier - router identity NAS-IP-Address - IP address of the router itself NAS-Port - unique session ID Acct-Session-Id - unique session ID Seems than Nas-Port + Acc-Session-id ( 2148532224 + 80100000 ) should be unique. I've sent an email to mikrotik to tell them that Acc-Session-id is not unique and know what they say (will share here if it helpful) So at that point I think, not sure yet, need to know if my radius is using class or not: If ussing class it would be solved modifying: &Acct-Unique-Session-Id := "%{md5:%{1},%{Acct-Session-ID}}" To &Acct-Unique-Session-Id := "%{md5:%{1},%{Acct-Session-ID}, %{NAS-Port} }" That should create in my case a really unique Acct-Unique-Session-Id Because if not using class: &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}" I think Acct-Unique-Session-Id will comes unique due NAS-Port is in md5 hash Is that correct ? I'm not going to change anything yet. Will wait to mikrotik answer. Thanks a agin for the suport I appreciate it. Rgds, -----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Alan DeKok Enviado el: domingo, 21 de abril de 2019 1:50 Para: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Asunto: Re: Radacct Reused ? On Apr 19, 2019, at 6:40 PM, Oscar <oscar@jofre.com> wrote:
I've serch and found the pice of code that I think creates the unique id
Yes.
I'm trying to understand why acctuniqueid=6cf28675aa2c38a046d7f46f65e36e72 has been created again
Because all of the values used to create it are the same.
and can't follow this code.
Where and what is the class I gess {%1} ? hex:&Class ? string:&Class ?
See "man unlang".
I think if in my case we go throw: &Acct-Unique-Session-Id := "%{md5:%{User-Name},%{Acct-Session-ID},%{%{NAS-IPv6-Address}:-%{NAS-IP-Address}},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}"
Then unique id can be reused because user-name and rest of values can be the same.
Yes.
Where comes the Acct-Session-ID ?
The NAS sends it. If you read the debug output, you will see this.
Sorry for too many questons ... but try to figure out how it works.
The short answer for the problem here is that the NAS is re-using values for sessions. It's not supposed to do that. The Acct-Session-Id is *supposed* to be mostly unique. If the NAS is this bad, then no amount of poking the FR config will fix it. There is literally nothing you can do to stop the problem of re-used sessions. You have to get a NAS which implements RADIUS properly. i.e. one that isn't garbage. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 21, 2019, at 4:31 PM, Oscar <oscar@jofre.com> wrote:
About:
Copying configuration files to the list isn't helpful.
Is Class an attribute that should come from the NAS ?
No.
I'm using mikroitk as a NAS and I think/hope is not garbage.
<shrug> If it's re-using Acct-Session-Id across different sessions, then yes, it's garbage.
This is what it is sending as accounting
22:14:40 radius,debug sending 3f:41a8 to 18.194.84.153:1813 22:14:40 radius,debug,packet sending Accounting-Request with id 14 to 18.194.84.153:1813 22:14:40 radius,debug,packet Signature = 0x72ab4a619fdecb98eeaefe7322abe9fe 22:14:40 radius,debug,packet Acct-Status-Type = 3 22:14:40 radius,debug,packet NAS-Port-Type = 19 22:14:40 radius,debug,packet Calling-Station-Id = "30:07:4D:50:64:AA" 22:14:40 radius,debug,packet Called-Station-Id = "8D0008D14A5D" 22:14:40 radius,debug,packet NAS-Port-Id = "bridge-hs" 22:14:40 radius,debug,packet User-Name = "SwB_3094873_ins_6971_30:07:4D:50:64:AA" 22:14:40 radius,debug,packet NAS-Port = 2148532224 22:14:40 radius,debug,packet Acct-Session-Id = "80100000"
That's really not a good idea. The Acct-Session-Id *should* be a long random string.
Seems than Nas-Port + Acc-Session-id ( 2148532224 + 80100000 ) should be unique.
Except when the same user logs into the same NAS port.
Is that correct ?
When I said no amount of poking FreeRADIUS would fix the NAS, I meant it. Your response should *not* be to poke the FreeRADIUS configuration in an attempt to "fix" the problem. Alan DeKok.
Hi Alan, 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.
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.
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.
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.
Best regards,
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. 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}}" But when there any many and many nas with the same behaver as me even this stronger unique id is not enough. 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". 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. Thanks, -----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Alan DeKok Enviado el: lunes, 22 de abril de 2019 14:33 Para: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Asunto: Re: Radacct Reused ? On Apr 21, 2019, at 4:31 PM, Oscar <oscar@jofre.com> wrote:
About:
Copying configuration files to the list isn't helpful.
Is Class an attribute that should come from the NAS ?
No.
I'm using mikroitk as a NAS and I think/hope is not garbage.
<shrug> If it's re-using Acct-Session-Id across different sessions, then yes, it's garbage.
This is what it is sending as accounting
22:14:40 radius,debug sending 3f:41a8 to 18.194.84.153:1813 22:14:40 radius,debug,packet sending Accounting-Request with id 14 to 18.194.84.153:1813 22:14:40 radius,debug,packet Signature = 0x72ab4a619fdecb98eeaefe7322abe9fe 22:14:40 radius,debug,packet Acct-Status-Type = 3 22:14:40 radius,debug,packet NAS-Port-Type = 19 22:14:40 radius,debug,packet Calling-Station-Id = "30:07:4D:50:64:AA" 22:14:40 radius,debug,packet Called-Station-Id = "8D0008D14A5D" 22:14:40 radius,debug,packet NAS-Port-Id = "bridge-hs" 22:14:40 radius,debug,packet User-Name = "SwB_3094873_ins_6971_30:07:4D:50:64:AA" 22:14:40 radius,debug,packet NAS-Port = 2148532224 22:14:40 radius,debug,packet Acct-Session-Id = "80100000"
That's really not a good idea. The Acct-Session-Id *should* be a long random string.
Seems than Nas-Port + Acc-Session-id ( 2148532224 + 80100000 ) should be unique.
Except when the same user logs into the same NAS port.
Is that correct ?
When I said no amount of poking FreeRADIUS would fix the NAS, I meant it. Your response should *not* be to poke the FreeRADIUS configuration in an attempt to "fix" the problem. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 3, 2019, at 11:10 AM, Oscar <oscar@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.
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@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@lists.freeradius.org> Asunto: Re: Radacct Reused ? On May 3, 2019, at 11:10 AM, Oscar <oscar@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
On May 3, 2019, at 11:46 AM, Oscar <oscar@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.
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@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@lists.freeradius.org> Asunto: Re: Radacct Reused ? On May 3, 2019, at 11:46 AM, Oscar <oscar@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
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@lists.freeradius.org> En nombre de Oscar Enviado el: domingo, 5 de mayo de 2019 16:12 Para: 'FreeRadius users mailing list' <freeradius-users@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@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@lists.freeradius.org> Asunto: Re: Radacct Reused ? On May 3, 2019, at 11:46 AM, Oscar <oscar@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 7, 2019, at 11:34 AM, Oscar <oscar@jofre.com> wrote:
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.
You can add another column and use that. It's usually better to add a new column, instead of re-using an existing one. Alan DeKok.
Hi, Good idea, I've searcha bit but haven't seen any example so I gess as you suggest I can add it and I don't need to change anything from inside freeraius setup. Is that easy ? Thanks, -----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Alan DeKok Enviado el: martes, 7 de mayo de 2019 19:17 Para: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Asunto: Re: Radacct Reused ? On May 7, 2019, at 11:34 AM, Oscar <oscar@jofre.com> wrote:
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.
You can add another column and use that. It's usually better to add a new column, instead of re-using an existing one. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 7, 2019, at 3:18 PM, Oscar <oscar@jofre.com> wrote:
Good idea, I've searcha bit but haven't seen any example so I gess as you suggest I can add it and I don't need to change anything from inside freeraius setup.
It's just a column in SQL. The SQL database documentation says how to modify SQL tables. Since FreeRADIUS doesn't know about the column, it will never read or write the column.
Is that easy ?
Yes, it's easy. Alan DeKok.
Hi, At the end I did finish the workaround to stop radius to reuse radacct old sessions when NAS is not sending a strong unique session id (acctsessionid) For me the problem was that mikrotik uses 1 hexa digit on acctsessionid that is incremented every reboot. For that NASes that are rebooted every day we will have after 16 days the same acctsessionid. So if the username that creates the first session is "always" the same we will end with the same acctsessionid+username that will generate the a acctuniqueid that has been created some days ago. So radius will reuse that session instead of creating a new one. To solve it I did create a daily job that for every session closed (acctstoptime not null) would regenerate de acctuniqueid with another one with timestamp that would make be unique "forever". Also to know the rows from radacct (sessions) that has ben updated I did create a new row on radacct called newuniqueid with 0 by default and 1 when acctuniqueid updated. In my case I use mysql. So this is the steps I've done 1) Alter Database ALTER TABLE `radius`.`radacct` ADD COLUMN `newuniqueid` TINYINT(4) NULL DEFAULT 0 AFTER `framedipaddress`; You can do this sentence and freeradius would still working because all the sql sentences used on freeradius only uses the rows needed. It takes me 25 minutes alter the table. 2) Update Database I did update radacct with the new acctuniqueid for all rows with acctstoptime not null. Updating also newuniqueid to 1 Be careful this update can take long time. I did break the update with radacctid<200000 , radacctid<400000 ... update radius.radacct set newuniqueid=1, acctuniqueid=md5(concat(username,acctsessionid,framedipaddress,acctuniqueid,UNIX_TIMESTAMP(acctupdatetime),UNIX_TIMESTAMP(acctstoptime))) where acctstoptime is not null and newuniqueid<>1 ; 3) Cron Job every day to "SAFE" sessions Every day at 1.30 I run a cron job that would update all acctstarttime between yesterday and 60 days ago with acctstoptime not null with the new acctuniqueid. 60 days ago would make create new uniqueid for that sessions that has been opened for more than 1 day. This is PHP peace of code $fFecIni = date('Y-m-d',strtotime("-60 days")); $fFecFin = date('Y-m-d',strtotime("-1 days")); $tFecha=" BETWEEN '".$fFecIni." 00:00:00' AND '".$fFecFin." 23:59:59'"; $tSql= "update radius.radacct set newuniqueid=1, acctuniqueid=md5(concat(username,acctsessionid,framedipaddress,acctuniqueid,UNIX_TIMESTAMP(acctupdatetime),UNIX_TIMESTAMP(acctstoptime))) where acctstarttime $tFecha and acctstoptime is not null and newuniqueid=0; "; Hope it's clear enough. Rgds, Oscar Jofre. -----Mensaje original----- De: Freeradius-Users <freeradius-users-bounces+oscar=jofre.com@lists.freeradius.org> En nombre de Alan DeKok Enviado el: miércoles, 08 de mayo de 2019 0:23 Para: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Asunto: Re: Radacct Reused ? On May 7, 2019, at 3:18 PM, Oscar <oscar@jofre.com> wrote:
Good idea, I've searcha bit but haven't seen any example so I gess as you suggest I can add it and I don't need to change anything from inside freeraius setup.
It's just a column in SQL. The SQL database documentation says how to modify SQL tables. Since FreeRADIUS doesn't know about the column, it will never read or write the column.
Is that easy ?
Yes, it's easy. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Oscar -
Oscar Jofre