I must be missing something, because even after the home_server has been marked as a zombie, the proxy is still ignoring the retransmits. Furthermore, it's taking much longer than the response_window for the home_server to be marked as a zombie.
rad_recv: Access-Request packet from host 127.0.0.1 port 39091, id=56, length=59 +- entering group authorize {...} ++[control] returns notfound +- entering group pre-proxy {...} [attr_filter.pre-proxy] expand: %{Realm} -> DEFAULT attr_filter: Matched entry DEFAULT at line 50 ++[attr_filter.pre-proxy] returns updated Sending Access-Request of id 175 to xxx.xxx.xxx.12 port 1812 Proxying request 0 to home server xxx.xxx.xxx.12 port 1812 Sending Access-Request of id 175 to xxx.xxx.xxx.12 port 1812 Going to the next request Waking up in 0.9 seconds. Waking up in 3.9 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 39091, id=56, length=59 Sending duplicate proxied request to home server xxx.xxx.xxx.12 port 1812 - ID: 175 Sending Access-Request of id 175 to xxx.xxx.xxx.12 port 1812 Rejecting request 0 due to lack of any response from home server xxx.xxx.xxx.12 port 1812 Found Post-Proxy-Type +- entering group Fail {...} ++[control] returns noop ++- entering policy do_not_respond {...}
That's why!
+++[control] returns noop +++[handled] returns handled ++- policy do_not_respond returns handled Going to the next request PROXY: Marking home server xxx.xxx.xxx.12 port 1812 as zombie (it looks like it is dead). Sending Status-Server of id 81 to xxx.xxx.xxx.12 port 1812 Message-Authenticator := 0x00000000000000000000000000000000 NAS-Identifier := "Status Check. Are you alive?" Waking up in 3.9 seconds. Waking up in 3.9 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 39091, id=56, length=59 Ignoring retransmit from client SERVERS port 39091 - ID: 56, no reply was configured
I can see your point. You would like to argue that the request should be taken of the list even if no response was configured - since server didn't respond because of the do_not_respond policy. I am not sure that can be made to work. Ivan Kalik Kalik Informatika ISP