Problems with freeradius accounting proxy

Phil Pierotti phil.pierotti at gmail.com
Tue Feb 16 09:37:36 CET 2010


Hi Fajar,

On Tue, Feb 16, 2010 at 1:16 PM, Fajar A. Nugraha <fajar at fajar.net> wrote:

> On Tue, Feb 16, 2010 at 6:09 AM, Phil Pierotti <phil.pierotti at gmail.com>
> wrote:
>
> > Tue Feb 16 09:40:25 2010 : Proxy: Marking home server 192.168.147.2 port
> > 1813 as zombie (it looks like it is dead).
>
> There should be other things before that
>
>
Yes, I agree, there *should* have been something more than that.

I pored over the log, carefully,  for a good while. Everything "looked
normal" (get a request, process it, proxy it, get reply, send it back,
lather/rinse/repeat). Nothing at all looking even slightly like "something
is wrong", until that message in the log.


> > Sending Accounting-Request of id 228 to 192.168.147.2 port 1813
> >         User-Name := "------------- at -------------"
> >         Acct-Status-Type := Stop
> >         Acct-Session-Id := "00000000"
> >         Event-Timestamp := "Feb 16 2010 09:40:25 EST"
> >         NAS-Identifier := "Status Check. Are you alive?"
> > Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.7 seconds.
> > rad_recv: Accounting-Response packet from host 192.168.147.2 port 1813,
> > id=228, length=20
> > Tue Feb 16 09:40:25 2010 : Proxy: Received response to status check 34 (1
> in
> > current sequence)
>
> Like that one. That particular status check was completed immediately.
> How were other status check responses, do they arrive on time? How
>

"on time" is subjective, but every status-check I saw came back within the
same second. the log has no finer granularity.

I would not be surprised if this is a case of "happy" replies are instant,
but anything with a problem is lagging. status-check is a known-good
condition (at least the user/pass) so it always succeeds, and is always
fast.


> about actual accounting request, do they get a timely response? It is
>

It could easily be that the downstream server is lagging in responsiveness ,
given that it's a db backend.
Best-case is snappy, worst-case is abysmal is not at all surprising with a
db.

But the question is how long before "timely" runs out? One second, ten
seconds, half-a-second?

Where (other than reading every single line of a debug log for an entire
day) can I find how happy (or not) freeradius is about a server it is
proxying to? This is a live radius proxy for a small ISP, not just a console
auth-server, so we're seeing anything up to ten requests per second - not
lots-n-lots, but also not practical to eyeball the entire thing in realtime.
Spot-checks are fine, but if nothing broke while you were checking then it's
"tree falls in a forest" time.

Thanks,
Phil P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100216/f2d52f2c/attachment.html>


More information about the Freeradius-Users mailing list