Hi Alan,<div><br></div><div>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.<br>

<div><br></div><div>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.</div><div><br></div><div>Meanwhile - on what basis does Freeradius decide that a downstream proxy is dead?</div>

<div><br></div><div>Thanks,</div><div>PhilP</div><div><br><br><div class="gmail_quote">On Tue, Feb 16, 2010 at 8:35 AM, Alan DeKok <span dir="ltr"><<a href="mailto:aland@deployingradius.com">aland@deployingradius.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Phil Pierotti wrote:<br>
> The main reason my initial checking was with tcpdump was to identify<br>
> what the packets were doing.<br>
<br>
</div>  As opposed to looking at the debug logs from the server?<br>
<br>
  You can look at the high level "packet in / packet out" view.  Or, you<br>
can look at the detailed log messages from the server saying what's<br>
going wrong, and why.<br>
<br>
  You chose the high-level view.  I'm trying to convince you to look at<br>
the informative view.  You don't seem to see this as useful.<br>
<div class="im"><br>
> So the problem is not due to the downstream RADIUS failing to respond at<br>
> all. (ie genuinely/obviously dead)<br>
<br>
</div>  There is a LOT more that can go on than just packet in / packet out.<br>
Maybe you might want to look for more information.<br>
<br>
  Since you've ALREADY looked at the tcpdump logs and they didn't<br>
help... maybe looking for MORE information would be a good idea.<br>
<div class="im"><br>
> Freeradius is deciding that my accounting proxy destination 'looks like<br>
> it is dead'.<br>
><br>
> Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}}<br>
> port 1813 as zombie (it looks like it is dead).<br>
<br>
</div>  If you had bothered to run the server in debugging mode, OR to use<br>
"raddebug" as I suggested, you might find out WHY this is happening.<br>
<br>
  Can you explain why you're not doing that?<br>
<div class="im"><br>
> I'm not entirely sure why, though. TCPDUMP shows a stream of accounting<br>
> requests being proxied to that server, and being received from that<br>
> server, while at the same time freeradius continues to log 'looks like<br>
> it is dead' messages.<br>
<br>
</div>  You've said that.  It's simply one step out of many.  For some reason,<br>
you can't get past "BUT PACKETS ARE GOING BACK AND FORTH".  You have<br>
refused to follow the instructions which can help you solve the problem.<br>
<div class="im"><br>
> Also, status check (via request) succeeds, naturally,  given that its<br>
> not the auth proxy that freeradius is complaining about.<br>
> (single downstream RADIUS configured as auth+acct)<br>
<br>
</div>  There is no "naturally" here.<br>
<br>
  Run in debugging mode.  Have I said that enough?  Is there anything<br>
else I need to say to convince you to run in debugging mode?<br>
<div><div></div><div class="h5"><br>
  Alan DeKok.<br>
-<br>
List info/subscribe/unsubscribe? See <a href="http://www.freeradius.org/list/users.html" target="_blank">http://www.freeradius.org/list/users.html</a><br>
</div></div></blockquote></div><br></div></div>