timeout and period values are rounded

[denis]

"It also has to be lower than max_request_time" - I did not see that in
docs.. may be missed.
If I said nothing about home server does not mean I'm not investigating
it's behaviour to get it fixed.
Besides home server issue those warning still looks questionable, so even
if it's not related I'd like at least to understand what's happening with
timeouts.
i.e for some reason even with max_request_time=30, setting
response_window=70 makes it 60, and 55 makes it 30.
zombie_period - setting 29 is fine, no warning. setting 20 - makes it 25.
so looks like in both cases there are some rules/additional dependencies
that are not in docs.

regards home server itself - reason I asked for undefined/non-specific
question about "best practices" is because yet I can't identify any
specific problem on home server. if proxy did not receive any response from
home server means either home did not get request, or response was not
received at all or came out of time range.
home server stats looks good for me:
# echo "Message-Authenticator = 0x00, FreeRADIUS-Statistics-Type = 2,
Response-Packet-Type = Access-Accept" | radclient -x localhost:18121 status
adminsecret
Sent Status-Server Id 9 from 0.0.0.0:54995 to 127.0.0.1:18121 length 50
        Message-Authenticator = 0x00
        FreeRADIUS-Statistics-Type = Accounting
        Response-Packet-Type = Access-Accept
Received Access-Accept Id 9 from 127.0.0.1:18121 to 0.0.0.0:0 length 104
        FreeRADIUS-Total-Accounting-Requests = 99554
        FreeRADIUS-Total-Accounting-Responses = 99507
        FreeRADIUS-Total-Acct-Duplicate-Requests = 0
        FreeRADIUS-Total-Acct-Malformed-Requests = 0
        FreeRADIUS-Total-Acct-Invalid-Requests = 0
        FreeRADIUS-Total-Acct-Dropped-Requests = 0
        FreeRADIUS-Total-Acct-Unknown-Types = 0

i.e in case of problems I guess Total-Acct-Dropped-Requests will increase,
right ?
so if you have any hints how to diagnose issue on home server - tel me
please.
for now I have only suggestion try to switch to tcp instead of udp.

--
Denis

On 9 July 2017 at 21:29, Alan DeKok <aland at deployingradius.com> wrote:

> On Jul 9, 2017, at 2:07 PM, denis <den.zinevich at gmail.com> wrote:
> >
> > I thought about bounds, but experiment showed that value is valid.
> > As I wrote in first mail:
> > WARNING: Ignoring "response_window = 60.000000", forcing to
> > "response_window = 30.000000" (response_window=60 in config)
> > WARNING: Ignoring "response_window = 70.000000", forcing to
> > "response_window = 60.000000" (response_window=70 in config)
> >
> > so 60 seems to be valid value, it's just not set with response_window=60
> > values response_window=25 or response_window=35 do not work as well
>
>   The response_window has to be lower than 60.  It also has to be lower
> than max_request_time.
>
>   And, you ignored Arran's other comments.
>
>   Stop arguing about irrelevant details.  Go fix the home server so that
> it doesn't take 30 seconds to respond.
>
>   No amount of poking the FreeRADIUS proxy will make the home server
> magically respond more quickly.
>
>   There is no possible value of "response_window" which will fix the
> problem.
>
>   Go fix the home server.  Stop arguing, and stop trying to create
> work-arounds.  Go fix the problem.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
>