"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@deployingradius.com> wrote:
On Jul 9, 2017, at 2:07 PM, denis <den.zinevich@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