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.
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. Ivan Kalik Kalik Informatika ISP