Robust Authentication Proxying

[Ivan Kalik]

> 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