<AuthBy RADIUS> forwards all
                  authentication and accounting requests for this Realm to another (possibly
                  remote) RADIUS server. This is called proxying. When the remote RADIUS
                  server replies, the reply is forwarded back to the client that originally
                  sent the request to the server.Host lines the requests can be forwarded to
                  primary/secondary RADIUS server pairs. The normal behaviour is to try to
                  forward the requests to the remote hosts in the order the hosts are listed
                  in the configuration file. This means that it initially tries to forward a
                  request to the first host listed (unless that host was marked as failed
                  recently). If no reply is received from the first host (after
                  Retries), it is marked as failed for
                  FailureBackoffTime seconds, and the request is
                  forwarded to the next Host in the list. This
                  continues until a reply is received, or until all the hosts are tried.
                  This way, if a primary remote server fails, the secondary takes over.
                  After FailureBackoffTime seconds, the primary is
                  tried again. To change this behaviour, choose other load balancing
                  versions of <AuthBy RADIUS>. For more
                  information, see Section 3.54. <AuthBy ROUNDROBIN>, <AuthBy VOLUMEBALANCE>, <AuthBy
                     LOADBALANCE>, <AuthBy HASHBALANCE>, <AuthBy
                     EAPBALANCE>.<AuthBy RADIUS>
                     clause is completed as soon as the request has been forwarded to the
                     remote RADIUS server. In this case, <AuthBy
                        RADIUS> returns IGNORE for
                     AuthByPolicy, so take care when using sequences of
                     AuthBy clauses that include <AuthBy RADIUS>.
                     <AuthBy RADIUS> does not wait for a reply
                     before moving on to other AuthBy clauses, or handling new requests. You
                     can change this behaviour with one of these flag parameters: Asynchronous
                     and Synchronous. Be cautious if you enable the Synchronous flag. It can
                     have a significant impact on performance. If you need to continue
                     processing the reply with another AuthBy clause, the correct way to do
                     that is with a ReplyHook or Asynchronous flag that was added to Radiator
                     4.17.<AuthBy
                        RADSEC> instead of <AuthBy
                        RADIUS>. RadSec provides encrypted, reliable transport of
                     RADIUS requests to a remote Radiator. For more information, see Section 3.71. <AuthBy RADSEC>,
                     Section 3.121. <ServerRADSEC>, and Section 16. RadSec (RFC 6614).<AuthBy ROUNDROBIN>, <AuthBy
                        VOLUMEBALANCE> or <AuthBy
                        LOADBALANCE> instead of <AuthBy
                        RADIUS>. For more information, see Section 3.54. <AuthBy ROUNDROBIN>, <AuthBy VOLUMEBALANCE>, <AuthBy
                        LOADBALANCE>, <AuthBy HASHBALANCE>, <AuthBy
                        EAPBALANCE>.<Host xxxxxx> clauses. For more
                     information, see Section 3.42.2. Host and Section 3.43. <Host xxxxxx> within <AuthBy RADIUS>.
                     The Host parameter is simpler but less flexible than the
                     <Host xxxxxx> clause. For ease of
                     understanding, do not mix formats in the same <AuthBy
                        RADIUS>.<AuthBy RADIUS>. It usually results in
                     requests being sent to the remote host, but the replies not
                     received.<AuthBy RADIUS>
      # Same secret and timeout for all hosts
      Secret xyzzy
      RetryTimeout 2
      Host host1.bigco.com
      Host host2.bigco.com
</AuthBy>
            <AuthBy RADIUS>
      # Same secret for all hosts
      Secret xyzzy
      <Host host1.bigco.com>
            # But a custom Timeout for this one
            RetryTimeout 2
      </Host>
      <Host host2.bigco.com>
            # And custom ports for this one
            AuthPort 1001
            AcctPort 1002
      </Host>
</AuthBy>
            <AuthBy RADIUS> understands also
                  the same parameters as <AuthBy xxxxxx>. For
                  more information, see Section 3.32. <AuthBy xxxxxx>.Retries 3 RetryTimeout 5 MaxFailedRequests 1 MaxFailedGraceTime 0 FailureBackoffTime 0
Host parameter, or you can use multiple
                  Host lines. Radiator tries up to Retries times to
                  contact each host that you specify. If no response it heard it tries the
                  next host in the list and so on until a reply is received or the list is
                  exhausted. The Host name can contain special formatting characters, which
                  are resolved at startup.# Send all requests for this realm to 198.51.100.2, if no reply # try the secondary at 198.51.100.3, if no reply from that, # try all the addresses that radiushosts.example.com resolves to # in round-robin fashion. Host 198.51.100.2,198.51.100.3 Host radiushosts.example.com
<Host
                        xxxxxx> clause, which allows you to customise details for
                     each host. For more information, see Section 3.43. <Host xxxxxx> within <AuthBy RADIUS>.
                     # These are equivalent to the lines in the example above:
<Host 198.51.100.2>
      # Put host-specific values for Secret, ports, 
      # retries etc. in here
</Host>
<Host 198.51.100.3>
</Host>
<Host radiushosts.example.com>
</Host>
                  <AuthBy RADIUS>
      # send via IPv6. Packets will appear to come from 
      # the default IPv6 source address for this host
      LocalAddress ::
      Host 2001:db8:100:f101::1
      Secret xxxxxx
      .....
</AuthBy>
                  # This better agree with the server at
# eric.open.com.au or they wont understand us
<AuthBy RADIUS>
      Host eric.open.com.au
      Secret 666obaFGkmRNs666
</AuthBy>
               # Send authentication to port 1812 on the remote server AuthPort 1812
# Send accounting to port 1813 on the remote server AcctPort 1813
OutPort 1001
3, which means maximum of 4
                  transmissions. This can be overridden for an individual host inside its
                  Host clause.Retries:# It is a poor link, so lots of retries Retries 10
# It is a poor link, wait 15 seconds before retransmission RetryTimeout 15
0 and keepalives are not used.
                  When UseStatusServerForFailureDetect is enabled,
                  KeepaliveTimeout together with
                  MaxFailedRequests and other related parameters
                  defines the minimum time it takes to notice the next hop has
                  failed.KeepaliveNoreplyTimeout defines, the
                  Status-Server request is marked as lost.KeepaliveNoreplyTimeout is not defined, the waiting
                  time value depends on the AuthBy you are using:<AuthBy RADCSEC>:
                     NoreplyTimeout value is used instead.<AuthBy RADIUS>:
                     RetryTimeout value is used instead.KeepaliveNoreplyTimeout and a larger value for
                  NoreplyTimeout or RetryTimeout.
                  The Status-Server responder is always the next hop host and a reply is
                  received quickly. With a short
                  KeepaliveNoreplyTimeout, a possible failure situation
                  is discovered quickly and the request is rerouted to another server. The
                  final destination of an Access-Request or an Accounting-Request message
                  may be located many hops away and for this reason a long
                  NoreplyTimeout may be needed.KeepaliveNoreplyTimeout and
                  NoreplyTimeout in <AuthBy
                     RADSEC>: <AuthBy RADSEC>
      NoreplyTimeout 10
      KeepaliveNoreplyTimeout 3
</AuthBy>
               <AuthBy RADIUS>, you must use
                  RetryTimeout instead of
                  NoreplyTimeout.KeepaliveRequestType with
                  AddToKeepaliveRequest:
                  # Send Access-Request as keepalive probe KeepaliveRequestType Access-Request AddToKeepaliveRequest User-Name=mikem,User-Password=fred
AddToKeepaliveRequest with
                  KeepaliveRequestType:
                  # Send Access-Request as keepalive probe KeepaliveRequestType Access-Request AddToKeepaliveRequest User-Name=mikem,User-Password=fred
NoreplyTimeout,
                  MaxFailedRequests, and
                  MaxFailedGraceTime during failure detection. This is
                  not enabled by default.FailureBackoffTime has
                  no effect when UseStatusServerForFailureDetect is
                  enabled. Once a Host has been marked as failed, it remains marked as
                  failed until a reply is received from it (typically in response to a
                  subsequent Status-Server request).KeepaliveTimeout is set to a sensible interval to
                  balance between detecting failures early and loading the target
                  server.MaxFailedRequests. If no reply is received when all
                  retries are used, the host is marked as failed and no requests are sent to
                  it. After FailureBackoffTime time has expired, the
                  Host is again eligible for forwarding. The unit is seconds, and the
                  default value is 0, which means that the host is always
                  regarded as working.MaxFailedRequests failures cause the
                  target host to be assumed to be failed. The default value is
                  0. After a host is declared to be failed, no request are
                  forwarded to it until FailureBackoffTime seconds have
                  elapsed. The default value lets the AuthBy to choose a reasonable value
                  which is typically very large. Very short values require a high number of
                  failures to set target host as failed. This value should only be changed
                  in special cases.Status-Server when this request type is used for
                     reachability detection.Radius::AuthRADSEC
                     structureRadius::Host structure for the
                     remote host$Radius::AuthRADIUS::HOST_STATE::REACHABLE$Radius::AuthRADIUS::HOST_STATE::UNREACHABLEHostStateChangeHook can be an arbitrarily
                  complicated Perl function, that might run external processes, consult
                  databases, change the contents of the current request or many other
                  things. The following example shows how to use the state constants, store
                  the state over hook invocations and log information from the
                  hook.HostStateChangeHook sub { \
    my ($p, $self, $host, $new_state, $ip, $port) = @_; \
    my $old_state = $host->{state_change_hook_current_state}; \
    $old_state = $Radius::AuthRADIUS::HOST_STATE::REACHABLE
        unless defined $old_state; \
    return if $old_state == $new_state; \
    $host->{state_change_hook_current_state} = $new_state; \
    my $st = ($new_state == $Radius::AuthRADIUS::HOST_STATE::UNREACHABLE) ?
             'Unreachable' : 'Reachable'; \
    my $msg = "HostStateChangeHook: IP '$ip', Port '$port', New State: '$st'"; \
    $self->log($main::LOG_INFO, "$self->{log_class_identifier} $msg", $p); \
    return; }
            0, which means there is no limit. If Radiator does not
                  receive a reply from a host, it keeps trying until all hosts are
                  exhausted.# Remove any NAS-IP-Address,NAS-Port attributes StripFromRequest NAS-IP-Address,NAS-Port
# Append a Filter-ID and host name AddToRequest Calling-Station-Id=1,Login-IP-Host=%h
AddToRequest, an attribute will only be added
                  if it does not already exist in the request. Value is a list of comma
                  separated attribute value pairs. You can use any of the special % formats
                  in the attribute values. There is no default.# Possibly add our default Operator-Name AddToRequestIfNotExist Operator-Name=1example.com
AuthBy RADIUS clause checks the value of
                  any Message-Authenticator attribute in incoming EAP
                  or other replies. An incorrect authenticator causes the request to be
                  ignored. RequireMessageAuthenticator flag causes the clause to
                  require a correct Message-Authenticator attribute to
                  be present in all incoming replies that support
                  Message-Authenticator attribute. Most of the message
                  types support Message-Authenticator. Accounting
                  requests and responses do not support
                  Message-Authenticator.# Just ACCEPT Authentication-Requests, do not forward them NoForwardAuthentication
# Just ACCEPT Accounting-Requests, do not forward them NoForwardAccounting
Acct-Status-Type attribute values that will be processed
                  in Accounting requests. The value is a comma-separated list of valid
                  Acct-Status-Type attribute values including,
                  Start, Stop, Alive,
                  Modem-Start, Modem-Stop,
                  Cancel, Accounting-On and
                  Accounting-Off. See your dictionary for a full
                  list.HandleAcctStatusTypes is specified and
                  an Accounting request has an Acct-Status-Type not
                  mentioned in HandleAcctStatusTypes, then the request
                  will be ACCEPTed but not otherwise processed by the enclosing clause. The
                  default is to handle all Acct-Status-Type
                  values.# Only process Start and Stop requests, ACCEPT and acknowledge everything else HandleAcctStatusTypes Start,Stop
# We are multi-homed, bind the proxy port so forwarded requests # appear to come from 203.53.154.27 LocalAddress 203.53.154.27
LocalAddress 203.63.154.27,2001:720:1500:1::a100 Host 2002:721:1500:1::a101 Host 210.1.1.5
# Change RadiusResult in the 3rd argument, the original request
ReplyHook sub { ${$_[2]}->{RadiusResult} = $main::ACCEPT; }
               # Fake a new attribute into the reply going back to the client
ReplyHook sub { ${$_[1]}->add_attr('test-attr', \
      'test-value');}
            # Call an AuthBy SQL to handle accounting that
# failed to get to the remote server
NoReplyHook sub { Radius::AuthGeneric::find('SQL')\
      ->handle_request(${$_[0]}, ${$_[2]});}
               ForwardHook receives the following
                  arguments:ForwardHook:
                  ForwardHook sub { my $p = $_[0]; my $fp = $_[1]; \
                  $fp->add_attr('OSC-AVPAIR', 'Added by ForwardHook'); }
               # If we get a reject from the remote, do not send it to the NAS IgnoreReject
<AuthBy RADIUS> and its
                  subclasses to return with result REJECT to trigger an Access-Reject when a
                  proxied request times out. This parameter is not set by
                  default.NoReplyReject is enabled, the
                  reject reason is set to 'Upstream timeout'.# Trigger an Access-Reject back to the NAS NoReplyReject
NoReplyReject
                     allows rejecting timed out requests without hooks such as
                     NoReplyHook. For more information, see Section 3.42.28. NoReplyHook<AuthBy
                     RADIUS> is to return IGNORE as soon as the request has been
                  forwarded to the remote RADIUS server. It does not wait for a reply before
                  moving on to other AuthBy classes, or handling new requests. You can
                  change this behaviour with the Asynchronous flag.
                  This flag is recommended for all new configurations.Asynchronous flag, Handler
                  continues to evaluate its AuthBy policy after a reply or timeout from the
                  remote proxy. Other requests are processed while the reply is pending.
                  Asynchronous is supported by <AuthBy
                     RADIUS> and its subclasses.# Auth to server1 and continue to AuthBy FILE if server 1 accepts.
# Process other requests while the reply from server 1 is pending.
<Handler>
      AuthByPolicy ContinueWhileAccept
      <AuthBy RADIUS>
            # Evaluate the policy when we get a reply or a timeout
            Asynchronous
            Host server1
            Secret xxxxxx
      </AuthBy>
      <AuthBy FILE>
            Filename %D/users
      </AuthBy>
</Handler>
            <AuthBy
                     RADIUS> is to return IGNORE as soon as the request has been
                  forwarded to the remote RADIUS server. It will not wait for a reply before
                  moving on to other AuthBy classes, or handling new requests. You can
                  change this behaviour with the Synchronous flag, but
                  make sure you understand what you are doing before enabling the
                  Synchronous flag.Synchronous flag, Radiator will wait for either a
                  reply, or a timeout from the remote radius server before processing any
                  following AuthBy clauses, or before handling any further requests. This
                  means that handling requests will stop until a reply is received or the
                  reply times out (which might take 15 seconds or more, depending on the
                  settings of your RetryTimeout and retries
                  parameters). This can seriously affect the performance of your RADIUS
                  server, especially if the remote radius server is slow, stopped, or at the
                  end of a slow or unreliable link. You should therefore be very cautious
                  about setting this flag, and you should understand the consequences of
                  remote server failure. The performance impact of the
                  Synchronous flag can be alleviated by use of the
                  Fork parameter (see Section 3.32.42. Fork) at the cost of significant
                  increase in memory requirements.Synchronous can be very handy if you wish, for
                  example, to forward a request to remote server only if another server
                  REJECTS the request. See the example below for sample
                  configuration.# Auth to server2 only if server 1 rejects. Caution: 
# accounting will normally go to server1, unless it rejects
<Realm xxxxxx>
      AuthByPolicy ContinueWhileReject
      <AuthBy RADIUS>
            # Wait here until we get a reply or a timeout
            Synchronous
            Host server1
            Secret xxxxxx
      </AuthBy>
      <AuthBy RADIUS>
            Host server2
            Secret yyy
      </AuthBy>
</Realm>
            # We are proxying to a GRIC server on NT ServerHasBrokenPortNumbers
ServerHasBrokenAddresses
"Bad authenticator received in reply ....."
AcctFailedLogFileName is defined, failed accounting
                  messages are not logged. The default is no logging. The file name can
                  include special formatting characters as described in Section 3.3. Special formatters, which means that,
                  for example, using the %c specifier, you can maintain separate accounting
                  log files for each Client. The AcctFailedLogFileName
                  file is always opened, written and closed for each failure, so you can
                  safely rotate it at any time.RewriteUsername is enabled.AcctLogFileFormat.# Log all accounting to a single log file in LogDir AcctFailedLogFileName %L/misseddetails
AcctLogFileFormatHook is not defined.
                  AcctLogFileFormat is a string containing special
                  formatting characters. It specifies the format for each line to be printed
                  to the accounting log file. A new line is automatically appended. It is
                  most useful if you use the %{attribute} style of
                  formatting characters (to print the value of the attributes in the current
                  packet.AcctLogFileFormat %{Timestamp} %{Acct-Session-Id}\
%{User-Name}
            AcctLogFileFormat or the default format is used. The
                  hook parameter is the reference to the current request.# We only want to forward Stops AccountingStopsOnly
# Strip everything except username and password AllowInRequest User-Name,User-Password
Gossip flag parameter enables this
                  AuthBy to send and listen for notifications (aka. gossip) to/from other
                  Radiator servers when any remote Radius server fails to reply. This is
                  disabled by default.goodies/farmsize.cfg for a
                  configuration sample.# Use the configured Gossip implementation for notifications Gossip
GossipNoReply flag parameter is
                  set, then a notification is sent when a remote Radius server fails to
                  reply. Radiator server also increases a counter for failed requests when a
                  notification is received. This is enabled by default.GossipHostDown flag parameter is
                  set, then a notification is sent when a remote Radius server is marked
                  down. Radiator server also marks the remote Radius server down when a
                  notification is received. This is enabled by default.GossipHostUp flag parameter is
                  set, then a notification will be send when a remote Radius server is
                  marked up and alive again. Radiator server also marks the remote Radius
                  server healthy when a notification is received. This is enabled by
                  default.