Hi {cut}

You will likely need to grab CVS head, as I've just committed a patch to fix some issues with reading the detail file.

It looks like there is still issue with reading from the file. From the debugging I did I think that the problem is with freeradius noticing that it already got to the end of the .work file and should close it. My C foo is not very strong, but it seems that the following line (616, detail.c) might be causing issues: if (((off_t) ftell(data->fp)) == buf.st_size) { I hope that helps. kind regards Pshem

{cut}

It looks like there is still issue with reading from the file. From the debugging I did I think that the problem is with freeradius noticing that it already got to the end of the .work file and should close it.

What does that mean?

That freeradius renames the detail file to detail.work, reads it and then stops. Debug shows it's ready to process requests but it just sits there. The first .work file never gets closed, so packets that arrive into new detail file never get processed.

My C foo is not very strong, but it seems that the following line (616, detail.c) might be causing issues:

if (((off_t) ftell(data->fp)) == buf.st_size) {

I hope that helps.

Nope.

As I said - my C skills are not very good. From my understanding - freeradius can't see that it got to the end of the .work file and it's time to close it and move on. Debug: FreeRADIUS Version 2.0.2-pre, for host i486-pc-linux-gnu, built on Feb 7 2008 at 13:16:02 Copyright (C) 1999-2008 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License. Starting - reading configuration files ... including configuration file /etc/test-freeradius2//radiusd.conf including configuration file /etc/test-freeradius2//proxy.conf including configuration file /etc/test-freeradius2//clients.conf including configuration file /etc/test-freeradius2//snmp.conf including configuration file /etc/test-freeradius2//sql-perhost.conf including configuration file /etc/test-freeradius2//sql/postgresql/counter.conf including configuration file /etc/test-freeradius2//policy.conf including files in directory /etc/test-freeradius2//sites-enabled/ including configuration file /etc/test-freeradius2//sites-enabled/local_logger including dictionary file /etc/test-freeradius2//dictionary main { prefix = "/usr" localstatedir = "/var" logdir = "/var/log/freeradius" libdir = "/usr/lib/freeradius" radacctdir = "/var/log/freeradius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 allow_core_dumps = yes pidfile = "/var/run/freeradius/freeradius.pid" user = "freerad" group = "freerad" checkrad = "/usr/sbin/checkrad" debug_level = 0 proxy_requests = yes security { max_attributes = 200 reject_delay = 1 status_server = yes } } client localhost { ipaddr = 127.0.0.1 netmask = 32 require_message_authenticator = no secret = "ihugrulz" nastype = "other" } client 10.119.20.191 { require_message_authenticator = no secret = "ihugrulz" shortname = "vt" } radiusd: #### Loading Realms and Home Servers #### radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating exec exec { wait = yes input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating expr Module: Linked to module rlm_expiration Module: Instantiating expiration expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating logintime logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server local_logger { modules { Module: Checking accounting {...} for more modules to load Module: Linked to module rlm_always Module: Instantiating ok always ok { rcode = "ok" simulcount = 0 mpp = no } } } server { modules { } } radiusd: #### Opening IP addresses and Ports #### listen { type = "detail" listen { filename = "/var/log/freeradius/radacct/detail_ftw" load_factor = 20 } } Listening on detail file /var/log/freeradius/radacct/detail_ftw as server local_logger Waking up in 1.0 seconds. detail_recv: Read packet from /var/log/freeradius/radacct/detail_ftw User-Name = "user" NAS-Port = 144528119 NAS-IP-Address = 10.119.255.90 Framed-IP-Address = a.b.c.d NAS-Identifier = "akl-grafton-bras1" Acct-Status-Type = Interim-Update Acct-Input-Octets = 6077376 Acct-Output-Octets = 59091227 Acct-Delay-Time = 602094 Proxy-State = 0x3237393635 Huntgroup-Name = "GLOBAL" Acct-Unique-Session-Id = "4ba74f9955303f6d" server local_logger { +- entering group accounting ++[ok] returns ok } # server local_logger Finished request 0. Going to the next request Waking up in 0.9 seconds. Cleaning up request 0 ID 44845 with timestamp +1 Ready to process requests. At this stage the .work file is still there, even after the packet from it was read already. configuration of the virtual server: server local_logger { listen { type = detail filename = ${radacctdir}/detail_ftw load_factor = 20 } accounting { ok } } After somewhat more debugging it looks like to problem only exists if the detail or detail.work files exist prior to starting freeradius. If I start with clean slate - everything works as expected. kind regards Pshem

On 08/02/2008, Alan DeKok <aland@deployingradius.com> wrote: {cut}

Please check that you've actually updated the source. The debug log you posted did NOT include the new debug messages I added as part of this fix. This suggests that you are NOT using the fix in your tests.

You were right - it looks like I had one cvs tree to many. Everything is working ok with the latest version. kind regards Pshem