Sorry, I didn't mean to imply I wasn't interested in looking further, my primary concern was to find out if it was something as simple and obvious as the downstream proxy not responding.

Thanks for your feedback, I'll look at the debug logs and see what they tell me, given the fairly frequent packets, that'll be a decent bit of reading.

Meanwhile - on what basis does Freeradius decide that a downstream proxy is dead?

Thanks,

PhilP

On Tue, Feb 16, 2010 at 8:35 AM, Alan DeKok <aland@deployingradius.com> wrote:

Phil Pierotti wrote:
> The main reason my initial checking was with tcpdump was to identify
> what the packets were doing.

As opposed to looking at the debug logs from the server?

You can look at the high level "packet in / packet out" view. Or, you
can look at the detailed log messages from the server saying what's
going wrong, and why.

You chose the high-level view. I'm trying to convince you to look at
the informative view. You don't seem to see this as useful.

> So the problem is not due to the downstream RADIUS failing to respond at
> all. (ie genuinely/obviously dead)

There is a LOT more that can go on than just packet in / packet out.
Maybe you might want to look for more information.

Since you've ALREADY looked at the tcpdump logs and they didn't
help... maybe looking for MORE information would be a good idea.

> Freeradius is deciding that my accounting proxy destination 'looks like
> it is dead'.
>
> Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}}
> port 1813 as zombie (it looks like it is dead).

If you had bothered to run the server in debugging mode, OR to use
"raddebug" as I suggested, you might find out WHY this is happening.

Can you explain why you're not doing that?

> I'm not entirely sure why, though. TCPDUMP shows a stream of accounting
> requests being proxied to that server, and being received from that
> server, while at the same time freeradius continues to log 'looks like
> it is dead' messages.

You've said that. It's simply one step out of many. For some reason,
you can't get past "BUT PACKETS ARE GOING BACK AND FORTH". You have
refused to follow the instructions which can help you solve the problem.

> Also, status check (via request) succeeds, naturally, given that its
> not the auth proxy that freeradius is complaining about.
> (single downstream RADIUS configured as auth+acct)

There is no "naturally" here.

Run in debugging mode. Have I said that enough? Is there anything
else I need to say to convince you to run in debugging mode?

Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html