On Jul 10, 2009, at 5:23 PM, Ivan Kalik wrote:
Yes, this is the configuration I'm currently running, and it's not
working for me. I have a radclient sending a request, retrying 10
times
on a 5-second timer, and after 10 retries, it still hasn't gotten a
response. After the second retry, the proxy has marked the server
as at
least a zombie and started status-checks, but every retransmit after
that is getting a cached result of no response.
What do you expect the proxy to do with requests sent to a home
server
that *might* be down? How should the proxy decide that the home
server
is down? Be specific. Draw flow diagrams...
This is what I want to happen
client req -> proxy
proxy req -> home server #1
client ret -> proxy
proxy ret -> home server #1
[proxy fails home server #1 for lack of response]
client ret -> proxy
proxy req -> home server #2
proxy <- resp home server #2
client <- resp proxy
You were told what to do: patch the source code so the request is
removed
from the list if do_not_respond policy is enabled. At present server
can
either respond or not respond to the request. It can't pretend it
never
recieved it as things stand now.
I did not see your message until after Alan's.
How do I configure that?
It can't be configured. Source needs to be patched.
My client's not going to retry the
request if he gets an Access-Reject, so I need the proxy to retry it.
What makes you think that? Users tend to retry dozen or so times with
wrong username/password/exired acount before they opt to try another
ISP
(in my case they have another 150 to choose from) or call the
helpline.
Small minority will actually check their account settings themselves
and
almost nobody will try only once and then give up - not unless they
have
tried and failed a few times previously.
I'm not using RADIUS as a backend for ISP gear. I am using a RADIUS
proxy to serve requests for service software, and when false failures
come back, customers get error boxes in their software and contact our
support angry that our authentications are returning transient
errors. Furthermore, I consider it bad public face to return errors
to customers when they should not get them. Yes, customers can always
retry, but we can also retry for them when know the reason is not due
to invalid information.
Thanks for your help guys. I do not want to sit there and beat a dead
horse. I will either patch the software or go with another piece of
software.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
