On Sep 15, 2023, at 6:33 AM, ANGEL LUIS MATEO MARTINEZ <amateo@um.es> wrote:
I have also found that the detail stored in the detail file used in the buffered-sql is wright:
Fri Sep 15 12:25:34 2023 ... Event-Timestamp = "Sep 15 2023 12:25:34 CEST" ... Acct-Delay-Time = 0
but this is the processed detail shown with freeradius -X:
detail (/datapool/radacct/acct_sql_log): Read packet from /datapool/radacct/acct_sql_log.work ... Event-Timestamp = "Sep 15 2023 13:25:34 CEST" ... Acct-Delay-Time = 4294963801
There are at a few issues here. We changed the time parsing in 3.0.22 to allow it to parse dates in the local language: https://github.com/FreeRADIUS/freeradius-server/issues/3602 This means that the server uses the time parsing functions from the local system. In this case, those functions are returning the wrong thing. It's not clear how to fix this cleanly. The time functions on your local system should work correctly. If we swap back to the previous (internal) time parsing method, then it will break for people who use a non-English language. In most cases, we also want to print the strings in humanly readable form. Because that's the easiest for everyone concerned. This issue is usually caused by time zone issues. i.e. the detail files are in one time zone, but the local machine is running in a different time. However, the local system here is both creating the detail files, and parsing them. So the conclusion is that the local time parsing functions are wrong, and create the wrong time. I've pushed a workaround: https://github.com/FreeRADIUS/freeradius-server/commit/1c00a9de25003566e970d... This will avoid the issue by printing dates as integers, which can't be parsed incorrectly. I've also pushed a fix so that updates to the Acct-Delay-Time don't create extreme values. Both of these fixes will be in the next 3.2.x release. Alan DeKok.