Re: Problems with freeradius accounting proxy
Phil Pierotti wrote: > Yes, I have no idea what to look for. If I did, I'd have been looking > for it, rather than asking the list. Maybe my messages haven't been clear enough. The people on this list know what to look for. But if you insist on giving *no* information for us to work with... we can't look. It's a puzzle, really. Q: I have a problem, can you help me? A: here are some steps you can take to debug it Q: Why the heck would I do that? A: Because you want to solve the problem? Q: Why are you being so mean to me? A: > Not withstanding your replies, I *still* am no closer to knowing *what* > to look for. (which is odd, because that was my original question) My original response stands: post the debug log, and let *us* look. You seem to have a problem with doing that. > Exactly how does freeradius identify a downstream radius as 'dead' ? It doesn't respond *correctly* to packets. > Clearly that's not as trivial as "no replies are received" because there > clearly are replies being received; tcpdump shows replies coming back > (ie the network stack sees acct-reply packets coming back from the > downstream server), the log shows replies coming back (so freeradius > sees them too). Can you explain why you're stuck on tcpdump? It's nearly irrelevant to the process. There are a *lot* of additional steps necessary for the packet to be deemed a "correct" response. And no, those steps aren't relevant for you. If the packet fails an additional step, the debug log will show it. Since you don't know what to look for, you could very likely miss it in the debug log. Hence.. the request for you to post the debug log so that *we* can read it. > Is a server declared 'dead' because one single request did not get a reply? > > More than one? > > More than two? > > Should I keep counting? How about reading the documentation in proxy.conf? This *is* documented. > Is there any way to find out how many 'missed' replies a downstream > server has? Read raddb/sites-available/status. This *is* documented. > Is there any way to tell freeradius to log in the debug messages *when* > it has given up and decided "ok, we've obviously missed that request". > (because there's no messages showing that with -X -xx) It does that already. If you're not seeing it, it's likely because you have home servers in a fail-over pool, and they are sporadically down. The proxy tries to fail over from one server to another. Since the packet is still "live", it's not considered to be "missed". Either post the debug log for us to look at, or stop pretending that you want the problem solved. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
On Tue, Feb 16, 2010 at 3:37 PM, Phil Pierotti wrote: >> 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? try /etc/raddb/proxy.conf # # If the home server doesn't respond to the request within # this time, this server will consider the request dead, and # respond to the NAS with an Access-Reject. # # If NO responses are received to any requests sent within this # time period, the home server will be marked "zombie", as below. # # Useful range of values: 5 to 60 response_window = 20 > > 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. Do you enable logging? /var/log/radius/radius.log is a good place to start. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Since you've deleted 99% of the debug log, I can't tell. Since you > don't know what to look for in the logs, you can't tell, either. > Yes, I have no idea what to look for. If I did, I'd have been looking for it, rather than asking the list. Not withstanding your replies, I *still* am no closer to knowing *what* to look for. (which is odd, because that was my original question) So , ignoring the previous discussion, I'll ask specific questions. (anyone please fee free to chip in) Exactly how does freeradius identify a downstream radius as 'dead' ? Clearly that's not as trivial as "no replies are received" because there clearly are replies being received; tcpdump shows replies coming back (ie the network stack sees acct-reply packets coming back from the downstream server), the log shows replies coming back (so freeradius sees them too). Is a server declared 'dead' because one single request did not get a reply? More than one? More than two? Should I keep counting? Is there any way to find out how many 'missed' replies a downstream server has? Is there any way to tell freeradius to log in the debug messages *when* it has given up and decided "ok, we've obviously missed that request". (because there's no messages showing that with -X -xx) Thanks, Phil P - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Hi Fajar, On Tue, Feb 16, 2010 at 1:16 PM, Fajar A. Nugraha wrote: > On Tue, Feb 16, 2010 at 6:09 AM, Phil Pierotti > 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 := "--...@-" > > Acct-Status-Type := Stop > > Acct-Session-Id := "" > > 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
On Tue, Feb 16, 2010 at 6:09 AM, Phil Pierotti 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 > Sending Accounting-Request of id 228 to 192.168.147.2 port 1813 > User-Name := "--...@-" > Acct-Status-Type := Stop > Acct-Session-Id := "" > 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 about actual accounting request, do they get a timely response? It is possible that the status check returns early due to non-existent record (Acct-Session-Id := "") needs no db write at all, while actual accounting requests received late response due to db write involved. As Alan said, a complete debug log would be able to show that (and possible other problems as well). You should be able to find out how long it takes for actual accounting packets to get response. If it's within reasonable limits, you may need to increase FR proxy timeouts so it doesn't declare the home server to be dead or zombie. However if it's dreadfully slow, your only choice is to fix your database, possibly tuning it or add faster disks. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Phil Pierotti wrote: > So I've run freeradius with -X -xx > > 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". They have rather a lot more than that. > No complaints, no explanation, no details, just jumps straight into > "looks like its dead". I doubt that very much. > This is the point at which freeradius decides the downstream has died. Once again... looking at only a tiny portion of the available data is wrong. You carefully deleted pretty much all of the debug log that might be useful. Is the server showing that it receives responses to the proxied packets? Since you've deleted 99% of the debug log, I can't tell. Since you don't know what to look for in the logs, you can't tell, either. Are you interested in solving the problem, or do you want to play games by not following instructions, and withholding information that could let us help you? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
So I've run freeradius with -X -xx 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". No complaints, no explanation, no details, just jumps straight into "looks like its dead". This is the point at which freeradius decides the downstream has died. Tue Feb 16 09:40:25 2010 : Info: ++[files] returns ok Sending Accounting-Request of id 180 to 192.168.147.2 port 1813 Acct-Session-Id = "00064089" Tunnel-Type:0 = L2TP Tunnel-Medium-Type:0 = IPv4 Tunnel-Server-Endpoint:0 = "192.168.92.1" Tunnel-Client-Endpoint:0 = "192.168.189.5" Tunnel-Assignment-Id:0 = "-" Tunnel-Client-Auth-Id:0 = "-" Tunnel-Server-Auth-Id:0 = "-" Acct-Tunnel-Connection = "2997106923" Framed-Protocol = PPP Tunnel-Medium-Type:0 = IPv4 Tunnel-Client-Endpoint:0 = "192.168.136.41" Tunnel-Server-Endpoint:0 = "192.168.136.44" Tunnel-Assignment-Id:0 = "-" Tunnel-Type:0 = L2TP Acct-Tunnel-Connection = "3093807349" Tunnel-Client-Auth-Id:0 = "-" Tunnel-Server-Auth-Id:0 = "-" User-Name := "--...@-" Cisco-AVPair = "connect-progress=Call Up" Acct-Session-Time = 58738 Acct-Input-Octets = 2042638912 Acct-Output-Octets = 82147247 Acct-Input-Packets = 2167463 Acct-Output-Packets = 1162476 Acct-Authentic = Local Acct-Status-Type = Interim-Update 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#" Service-Type = Framed-User NAS-IP-Address = 192.168.144.10 Acct-Delay-Time = 2 Proxy-State = 0x3936 Tue Feb 16 09:40:25 2010 : Info: Proxying request 33 to home server 192.168.147.2 port 1813 Sending Accounting-Request of id 180 to 192.168.147.2 port 1813 Acct-Session-Id = "00064089" Tunnel-Type:0 = L2TP Tunnel-Medium-Type:0 = IPv4 Tunnel-Server-Endpoint:0 = "192.168.92.1" Tunnel-Client-Endpoint:0 = "192.168.189.5" Tunnel-Assignment-Id:0 = "-" Tunnel-Client-Auth-Id:0 = "-" Tunnel-Server-Auth-Id:0 = "-" Acct-Tunnel-Connection = "2997106923" Framed-Protocol = PPP Tunnel-Medium-Type:0 = IPv4 Tunnel-Client-Endpoint:0 = "192.168.136.41" Tunnel-Server-Endpoint:0 = "192.168.136.44" Tunnel-Assignment-Id:0 = "-" Tunnel-Type:0 = L2TP Acct-Tunnel-Connection = "3093807349" Tunnel-Client-Auth-Id:0 = "-" Tunnel-Server-Auth-Id:0 = "-" User-Name := "--...@-" Cisco-AVPair = "connect-progress=Call Up" Acct-Session-Time = 58738 Acct-Input-Octets = 2042638912 Acct-Output-Octets = 82147247 Acct-Input-Packets = 2167463 Acct-Output-Packets = 1162476 Acct-Authentic = Local Acct-Status-Type = Interim-Update 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#" Service-Type = Framed-User NAS-IP-Address = 192.168.144.10 Acct-Delay-Time = 2 Proxy-State = 0x3936 Tue Feb 16 09:40:25 2010 : Debug: Going to the next request Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.1 seconds. 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). Sending Accounting-Request of id 228 to 192.168.147.2 port 1813 User-Name := "--...@-" Acct-Status-Type := Stop Acct-Session-Id := "" 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) Tue Feb 16 09:40:25 2010 : Debug: Waking up in 0.7 seconds. Thanks, Phil P On Tue, Feb 16, 2010 at 9:11 AM, Phil Pierotti wrote: > Hi Alan, > > 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 wrote: > >> Phil Pierotti wrote: >> > The main reason my initial checking was with tcpdump was to ident
Re: Problems with freeradius accounting proxy
Hi Fajar,
Yes and no, it's a third-party product integrated into our billing system,
so it's 100% "mystery magic".
Debugging is strictly "ask someone to fix it because its broken".
Re: your comments about database lookups, this is exactly the situation.
Thanks,
Phil P
On Tue, Feb 16, 2010 at 8:56 AM, Fajar A. Nugraha wrote:
> On Tue, Feb 16, 2010 at 4:00 AM, Phil Pierotti
> wrote:
> > Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}} port
> > 1813 as zombie (it looks like it is dead).
>
> I assume that radius is out of your control?
>
> > 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)
>
> Running in debugging mode, or at least looking at FR logs, might show
> you what's happening. I suspect the home server is taking a long time
> processing acct packets. This is somewhat common if (for example) the
> home server uses database for acct, with lots of rows and index, an
> slow disks, in such a way that writes/updates takes a long time. This
> is just a guess though, more info should be available from the log.
>
> --
> Fajar
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Hi Alan,
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 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
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
On Tue, Feb 16, 2010 at 4:00 AM, Phil Pierotti wrote:
> Tue Feb 16 07:45:32 2010 : Proxy: Marking home server {{radius-ip}} port
> 1813 as zombie (it looks like it is dead).
I assume that radius is out of your control?
> 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)
Running in debugging mode, or at least looking at FR logs, might show
you what's happening. I suspect the home server is taking a long time
processing acct packets. This is somewhat common if (for example) the
home server uses database for acct, with lots of rows and index, an
slow disks, in such a way that writes/updates takes a long time. This
is just a guess though, more info should be available from the log.
--
Fajar
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
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
Re: Problems with freeradius accounting proxy
Hi Alan,
The main reason my initial checking was with tcpdump was to identify what
the packets were doing.
ACCT request IN from LNS - check
ACCT request OUT to downstream RADIUS - no
So the problem is not due to the downstream RADIUS failing to respond at
all. (ie genuinely/obviously dead)
Overnight I upgraded to 2.1.8, and now the behavior has changed, slightly.
Freeradius is complaining in the logs, but now it looks like enough
back-n-forth is happening that my LNS doesn't lose its mind any more.
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).
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.
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)
Thanks,
Phil P
Tue Feb 16 07:46:31 2010 : Proxy: Received response to status check 68398
(563 in current sequence)
On Mon, Feb 15, 2010 at 6:23 PM, Alan DeKok wrote:
> Phil Pierotti wrote:
> > TCPDUMP shows the accounting requests are still being received on the
> > freeradius box, but the outbound/proxied messages have just stopped.
> >
> > Any suggestions as to what might be wrong/where to look?
>
> The logs from the server?
>
> I don't understand why you're looking at tcpdump, and not the
> FreeRADIUS logs.
>
> In 2.1.7, you can also use "raddebug" to get the debug logs from a
> running server.
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
Phil Pierotti wrote: > TCPDUMP shows the accounting requests are still being received on the > freeradius box, but the outbound/proxied messages have just stopped. > > Any suggestions as to what might be wrong/where to look? The logs from the server? I don't understand why you're looking at tcpdump, and not the FreeRADIUS logs. In 2.1.7, you can also use "raddebug" to get the debug logs from a running server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with freeradius accounting proxy
I've upgraded to 2.1.8 , and still the same. Oddly enough, it says the *ACCT* port is zombie (which it isn't , we're still seeing responses frequently). *and* the "un-zombie" recovery does an AUTH, so there is no case where the ACCT port will UN zombify. Phil P On Mon, Feb 15, 2010 at 1:42 PM, Phil Pierotti wrote: > Hi All, > > I've got Freeradius (2.1.7, Ubuntu Hardy) setup to answer some requests > itself, and others get proxied away. > All accounting requests get proxied away. > > My Cisco LNS is sending periodic accounting requests , every ten minutes. > > We have enough concurrent sessions online that there's a steady rain of > accounting packets, about one-3 per second on average. > > After some reasonably short period of time (currently approx 30-40 minutes) > Freeradius stops responding to accounting requests. > > Auth requests (when they happen) are still fine, however because our auth > volume is low, our Cisco ends up seeing the lack of response to accounting > messages as 'dead radius', and no further auth attempts are being sent. > > > TCPDUMP shows the accounting requests are still being received on the > freeradius box, but the outbound/proxied messages have just stopped. > > Any suggestions as to what might be wrong/where to look? > > Phil P > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Problems with freeradius accounting proxy
Hi All, I've got Freeradius (2.1.7, Ubuntu Hardy) setup to answer some requests itself, and others get proxied away. All accounting requests get proxied away. My Cisco LNS is sending periodic accounting requests , every ten minutes. We have enough concurrent sessions online that there's a steady rain of accounting packets, about one-3 per second on average. After some reasonably short period of time (currently approx 30-40 minutes) Freeradius stops responding to accounting requests. Auth requests (when they happen) are still fine, however because our auth volume is low, our Cisco ends up seeing the lack of response to accounting messages as 'dead radius', and no further auth attempts are being sent. TCPDUMP shows the accounting requests are still being received on the freeradius box, but the outbound/proxied messages have just stopped. Any suggestions as to what might be wrong/where to look? Phil P - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
