On Mar 1, 2016, at 5:14 AM, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
I found my last outstanding bug before I deploy my configuration and it's got me stumped.
When a Proxy server is down I would like to choose between sending a reject or not sending a response at all.
Is there a way that do_not_respond will be honored on 3.0.11 is a post-proxy failure situation?
The internal checks for "do not respond" happen just before the response is sent. They are entirely independent of proxying.
Marking home server 222.222.222.1 port 1812 as zombie (it has not responded in 1.000000 seconds). (0) ERROR: Failing proxied request for user "peter", due to lack of any response from home server 222.222.222.1 port 1812 (0) Clearing existing &reply: attributes (0) Found Post-Proxy-Type Fail-Authentication (0) # Executing group from file ./sites-enabled/default (0) Post-Proxy-Type Fail-Authentication { (0) policy do_not_respond { (0) update control { (0) &Response-Packet-Type := Do-Not-Respond
That's good...
(0) } # update control = noop (0) [handled] = handled (0) } # policy do_not_respond = handled (0) } # Post-Proxy-Type Fail-Authentication = handled (0) There was no response configured: rejecting request
That's weird. Look in src/main/process.c for that message. 5 lines above, it checks for the "do not respond" attribute. i.e. the only way that message shows up is if there's no control:Response-Packet-Type. I've pushed a fix. Alan DeKok.