[RE]Problem with proxied accounting

[Alan DeKok]

Cristina Miyata wrote:
> We have just upgraded to FreeRADIUS 2.1.6, but unfortunately the problem persists:
>
> Server1/:
> total 1008236
> -rw-------  1 root root 714751062 Jul 29 11:53 detail-20090729
> -rw-------  1 root root 316653344 Jul 29 07:29 detail.work <= stuck!

  A 700M detail file?  Wow... it should really be rather a lot smaller
than that.

  I would suggest adding %H (at least) to the filename, which will
shrink them in size by a factor of 24.

> We got sometimes the following message for Server2:
> 
> Thu Jul 23 15:00:45 2009 : Proxy: No outstanding request was found for proxy reply from home server <Server2 IP address> port 1813 - ID 142
> And several messages for Server1:
> 
> Wed Jul 29 11:36:53 2009 : Error: Rejecting request 3993531 due to lack of any response from home server <Server1 IP address> port 1813
> Wed Jul 29 11:36:53 2009 : Error: PROXY: Marking home server <Server1 IP address> port 1813 as zombie (it looks like it is dead).
> Wed Jul 29 11:37:28 2009 : Info: Suspicious proxy state... continuing
> Wed Jul 29 11:37:30 2009 : Error: Rejecting request 3998634 due to lack of any response from home server <Server1 IP address> port 1813

  Your home servers are dead or dying.  That's not good.

> In an attempt to force the revival of Server1, we scheduled the execution of the following command every minute:
> 
> radmin -e "set home_server state <Server1 IP address> 1813 alive"

  Uh... that won't help.  What happens when it's still down?  This is a
*very* bad idea.

  You should use the normal status checks to determine if a home server
is alive.

> But still, it seems to stuck ... I checked with "tcpdump port 1813 and host <Server1 IP address>" that even though the details.work for Server1 is freezed, FreeRADIUS is sending accounting requests to Server1 and it is receiving accounting responses.

  Yes.... it doesn't *modify* the detail file while it's being
processed.  It processes the whole file, (sending packets the whole
time), and then deletes the file when it's done.

  If the home servers are almost down, it will *continue* to process the
detail file, and it will *continue* to send packets until it's done.

  That's what you're seeing.  If the home servers are down, it will STOP
proxying packets, and it will STOP reading the detail file... because
the home servers are down.

> I have many many questions of how FreeRADIUS proxy works. Could someone please help us understand what we doing wrong?

  The entire functionality of proxying is documented in the
configuration files.

> 1) Do you think that Server1 detail.work get "stuck", because FreeRADIUS detected that some of the accouting requests in the detail.work didn't have a response from Server1?

  That is how the process is *documented* as working.  See
raddb/sites-available/copy-acct-to-home-server.

> 2) FreeRADIUS is still sending accounting requests and receiving responses for Server1, just because we are setting Server1 alive? When we do this, it starts processing the details.work from the beginning of the file? After sometime, FreeRADIUS proxy stops completely. Is it because FreeRADIUS had too many accounting requests without responses?

  I have no idea what that means.

> 3) Server1 receives all accounting requests received by FreeRADIUS, and Server2 receives accounting requests that matches a filter. I've noticed that Server1 and Server2 accounting responses for the same accounting requests have the same Packet Identifier, and that the NAS frequently reuses this Packet Identifier. Do you think that FreeRADIUS can get lost in this situation?

  No.

  Alan DeKok.