Alan, I used the example configuration and got the same result.

...

...

Sending proxied request internally to virtual server. server acct_detail.example.com { +- entering group accounting {...} [detail.example.com] Suppressing writes to detail file as the request was just read from a detail file.++[detail.example.com] returns noop } # server acct_detail.example.com Going to the next request <<< Received proxied response from internal virtual server. server home.example.com { }

1) The following is in the robust-proxy-accounting file. # (5) Define the virtual server to write the packets to the detail file # This will be called when ALL home servers are down, because of the # "fallback" configuration in the home server pool. server acct_detail.example.com { accounting { detail.example.com } } # (6) Define a virtual server to handle pre/post-proxy re-writing server home.example.com { pre-proxy { # Insert pre-proxy rules here } post-proxy { # Insert post-proxy rules here # This will be called when the CURRENT packet failed # to be proxied. This may happen when one home server # suddenly goes down, even though another home server # may be alive. # # i.e. the current request has run out of time, so it # cannot fail over to another (possibly) alive server. # # We want to respond to the NAS, so that it can stop # re-sending the packet. We write the packet to the # "detail" file, where it will be read, and sent to # another home server. # Post-Proxy-Type Fail { detail.example.com } } # Read accounting packets from the detail file(s) for # the home server. # # Note that you can have only ONE "listen" section reading # detail files from a particular directory. That is why the # destination host name is used as part of the directory name # below. Having two "listen" sections reading detail files # from the same directory WILL cause problems. The packets # may be read by one, the other, or both "listen" sections. listen { type = detail filename = "${radacctdir}/detail.example.com/detail-*:*" load_factor = 10 } # All packets read from the detail file are proxied back to # the home servers. # # The normal pre/post-proxy rules are applied to them, too. # # If the home servers are STILL down, then the server stops # reading the detail file, and queues the packets for a later # retransmission. The Post-Proxy-Type "Fail" handler is NOT # called. # # When the home servers come back up, the packets are forwarded, # and the detail file processed as normal. accounting { # You may want accounting policies here... update control { Proxy-To-Realm := "acct_realm.example.com" } } } 2. I moved the following from the robust-proxy-accounting file to the proxy.conf file. # (1) Define two home servers. home_server home1.example.com { type = acct ipaddr = 129.11.162.17 port = 1813 secret = <remvoved> # Mark this home server alive ONLY when it starts being responsive status_check = status-server #status_check = request #username = "test_user_status_check" # Set the response timeout aggressively low. # You MAY have to increase this, depending on tests with # your local installation. response_window = 6 } # (2) Define a virtual server to be used when both of the # home servers are down. home_server acct_detail.example.com { virtual_server = acct_detail.example.com } # Put all of the servers into a pool. home_server_pool acct_pool.example.com { type = load-balance # other types are OK, too. home_server = home1.example.com # add more home_server's here. # If all home servers are down, try a home server that # is a local virtual server. fallback = acct_detail.example.com # for pre/post-proxy policies virtual_server = home.example.com } # (3) Define a realm for these home servers. # It should NOT be used as part of normal proxying decisions! realm acct_realm.example.com { acct_pool = acct_pool.example.com } Chris Howley