So I've run freeradius with -X -xx <div><br></div><div>Other than logging the details of the packets sent and received, the debug logs do not have much more than "marking as zombie, seems to be dead".<div><br>

</div><div><div><div>No complaints, no explanation, no details, just jumps straight into "looks like its dead".</div></div><div><br></div><div><div><br></div><div><br></div><div>This is the point at which freeradius decides the downstream has died.</div>

<div><br></div><div>Tue Feb 16 09:40:25 2010 : Info: ++[files] returns ok</div><div>Sending Accounting-Request of id 180 to 192.168.147.2 port 1813</div><div>        Acct-Session-Id = "00064089"</div><div>        Tunnel-Type:0 = L2TP</div>

<div>        Tunnel-Medium-Type:0 = IPv4</div><div>        Tunnel-Server-Endpoint:0 = "192.168.92.1"</div><div>        Tunnel-Client-Endpoint:0 = "192.168.189.5"</div><div>        Tunnel-Assignment-Id:0 = "-------------"</div>

<div>        Tunnel-Client-Auth-Id:0 = "-------------"</div><div>        Tunnel-Server-Auth-Id:0 = "-------------"</div><div>        Acct-Tunnel-Connection = "2997106923"</div><div>        Framed-Protocol = PPP</div>

<div>        Tunnel-Medium-Type:0 = IPv4</div><div>        Tunnel-Client-Endpoint:0 = "192.168.136.41"</div><div>        Tunnel-Server-Endpoint:0 = "192.168.136.44"</div><div>        Tunnel-Assignment-Id:0 = "-------------"</div>

<div>        Tunnel-Type:0 = L2TP</div><div>        Acct-Tunnel-Connection = "3093807349"</div><div>        Tunnel-Client-Auth-Id:0 = "-------------"</div><div>        Tunnel-Server-Auth-Id:0 = "-------------"</div>

<div>        User-Name := "-------------@-------------"</div><div>        Cisco-AVPair = "connect-progress=Call Up"</div><div>        Acct-Session-Time = 58738</div><div>        Acct-Input-Octets = 2042638912</div>

<div>        Acct-Output-Octets = 82147247</div><div>        Acct-Input-Packets = 2167463</div><div>        Acct-Output-Packets = 1162476</div><div>        Acct-Authentic = Local</div><div>        Acct-Status-Type = Interim-Update</div>

<div>        Calling-Station-Id = "GigabitEthernet 8/0.31100305:3110-305#587265364###pppoe 00:1e:2a:13:24:28#QTORQE17M atm 1/1/14/32:8.35#"</div><div>        Service-Type = Framed-User</div><div>        NAS-IP-Address = 192.168.144.10</div>

<div>        Acct-Delay-Time = 2</div><div>        Proxy-State = 0x3936</div><div>Tue Feb 16 09:40:25 2010 : Info: Proxying request 33 to home server 192.168.147.2 port 1813</div><div>Sending Accounting-Request of id 180 to 192.168.147.2 port 1813</div>

<div>        Acct-Session-Id = "00064089"</div><div>        Tunnel-Type:0 = L2TP</div><div>        Tunnel-Medium-Type:0 = IPv4</div><div>        Tunnel-Server-Endpoint:0 = "192.168.92.1"</div><div>        Tunnel-Client-Endpoint:0 = "192.168.189.5"</div>

<div>        Tunnel-Assignment-Id:0 = "-------------"</div><div>        Tunnel-Client-Auth-Id:0 = "-------------"</div><div>        Tunnel-Server-Auth-Id:0 = "-------------"</div><div>        Acct-Tunnel-Connection = "2997106923"</div>

<div>        Framed-Protocol = PPP</div><div>        Tunnel-Medium-Type:0 = IPv4</div><div>        Tunnel-Client-Endpoint:0 = "192.168.136.41"</div><div>        Tunnel-Server-Endpoint:0 = "192.168.136.44"</div>

<div>        Tunnel-Assignment-Id:0 = "-------------"</div><div>        Tunnel-Type:0 = L2TP</div><div>        Acct-Tunnel-Connection = "3093807349"</div><div>        Tunnel-Client-Auth-Id:0 = "-------------"</div>

<div>        Tunnel-Server-Auth-Id:0 = "-------------"</div><div>        User-Name := "-------------@-------------"</div><div>        Cisco-AVPair = "connect-progress=Call Up"</div><div>        Acct-Session-Time = 58738</div>

<div>        Acct-Input-Octets = 2042638912</div><div>        Acct-Output-Octets = 82147247</div><div>        Acct-Input-Packets = 2167463</div><div>        Acct-Output-Packets = 1162476</div><div>        Acct-Authentic = Local</div>

<div>        Acct-Status-Type = Interim-Update</div><div>        Calling-Station-Id = "GigabitEthernet 8/0.31100305:3110-305#587265364###pppoe 00:1e:2a:13:24:28#QTORQE17M atm 1/1/14/32:8.35#"</div><div>        Service-Type = Framed-User</div>

<div>        NAS-IP-Address = 192.168.144.10</div><div>        Acct-Delay-Time = 2</div><div>        Proxy-State = 0x3936</div><div>Tue Feb 16 09:40:25 2010 : Debug: Going to the next request</div><div>Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.1 seconds.</div>

<div>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).</div><div>Sending Accounting-Request of id 228 to 192.168.147.2 port 1813</div><div>        User-Name := "-------------@-------------"</div>

<div>        Acct-Status-Type := Stop</div><div>        Acct-Session-Id := "00000000"</div><div>        Event-Timestamp := "Feb 16 2010 09:40:25 EST"</div><div>        NAS-Identifier := "Status Check. Are you alive?"</div>

<div>Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.7 seconds.</div><div>rad_recv: Accounting-Response packet from host 192.168.147.2 port 1813, id=228, length=20</div><div>Tue Feb 16 09:40:25 2010 : Proxy: Received response to status check 34 (1 in current sequence)</div>

<div>Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.7 seconds.</div></div><div><br></div><div><br></div><div>Thanks,</div><div>Phil P<br><br><div class="gmail_quote">On Tue, Feb 16, 2010 at 9:11 AM, Phil Pierotti <span dir="ltr"><<a href="mailto:phil.pierotti@gmail.com">phil.pierotti@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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><div></div><div class="h5"><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" target="_blank">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>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><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><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><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><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><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></div></div>
</blockquote></div><br></div></div></div>