Adding upstream version 3.2.1+dfsg.upstream/3.2.1+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

22 files changed, 3301 insertions, 0 deletions

diff --git a/man/man5/checkrad.5 b/man/man5/checkrad.5
new file mode 100644
index 0000000..68a33f4
--- /dev/null
+++ b/man/man5/checkrad.5
@@ -0,0 +1,95 @@
+.TH CHECKRAD 5 "13 January 2006"
+.SH NAME
+checkrad -- See if a user is (still) logged in on a certain port.
+.SH SYNOPSIS
+.B checkrad
+.RB [ -d ]
+.I nas-type nas-ip nas-port login session-id
+.SH DESCRIPTION
+\fBCheckrad\fP is used by the radius server to check if its idea of a user logged in
+on a certain port/NAS is correct if a double login is detected.
+
+Returns: 0 = no duplicate, 1 = duplicate, >1 = error.
+
+.SH OPTIONS
+
+.IP -d
+Enable printing of debugging information.
+
+.IP nas-type
+Type of port/NAS. Can be one of:
+
+.RS
+.IP \(bu
+ascend
+.IP \(bu
+bay
+.IP \(bu
+cisco
+.IP \(bu
+cisco_l2tp
+.IP \(bu
+computone
+.IP \(bu
+cvx
+.IP \(bu
+digitro
+.IP \(bu
+dot1x
+.IP \(bu
+livingston
+.IP \(bu
+max40xx
+.IP \(bu
+mikrotik
+.IP \(bu
+mikrotik_snmp
+.IP \(bu
+multitech
+.IP \(bu
+netserver
+.IP \(bu
+other
+.IP \(bu
+pathras
+.IP \(bu
+patton
+.IP \(bu
+portslave
+.IP \(bu
+pr3000
+.IP \(bu
+pr4000
+.IP \(bu
+redback
+.IP \(bu
+tc
+.IP \(bu
+usrhiper
+.IP \(bu
+versanet
+.P
+The "other" type cause \fBcheckrad\fP to skip any check and always returns 1.
+.RE
+
+
+.IP nas-ip
+IP address of the NAS to check.
+
+.IP nas-port
+The NAS port to check (may be ignored by some nas-type).
+
+.IP login
+The login name to check.
+
+.IP session-id
+Session to check. (actually ignored by all nas-type)
+
+.SH SEE ALSO
+radiusd(8)
+
+.SH AUTHOR
+Written by Miquel van Smoorenburg, miquels@cistron.nl.
+
+This manual page was written by Marco Nenciarini <mnencia@debian.org> for
+the Debian project (but may be used by others).
diff --git a/man/man5/clients.conf.5 b/man/man5/clients.conf.5
new file mode 100644
index 0000000..6c6b3ee
--- /dev/null
+++ b/man/man5/clients.conf.5
@@ -0,0 +1,46 @@
+.TH clients.conf 5 "13 June 2005" "" "FreeRADIUS client configuration"
+.SH NAME
+clients.conf \- FreeRADIUS client configuration
+.SH DESCRIPTION
+The 
+.I clients.conf
+file contains definitions of RADIUS clients.
+.PP
+The information in this file overrides any information provided in
+the deprecated 
+.BR clients
+and 
+.BR naslist
+files.
+.PP
+The file format is the same as that used for
+.I radiusd.conf.
+See 
+.BR radiusd.conf (5)
+for more details.
+.PP
+Each RADIUS client entry has the following basic form:
+.IP
+.nf
+client <short-name> {
+       <attribute> = <value>
+ }
+.fi
+.PP
+Clients have many configuration parameters. Most are documented in the file
+itself as comments. This page documents only the format of the file. Please
+read the \fBclients.conf\fP file itself for more information.
+
+The old-style format from 1.x is still accepted by the server, but
+that form is deprecated.
+.SH FILES
+.I /etc/raddb/clients.conf
+
+.I /etc/raddb/radiusd.conf
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+
+.SH AUTHOR
+FreeRADIUS is authored by the FreeRADIUS team. 
+http://freeradius.org/
diff --git a/man/man5/dictionary.5 b/man/man5/dictionary.5
new file mode 100644
index 0000000..ec63309
--- /dev/null
+++ b/man/man5/dictionary.5
@@ -0,0 +1,185 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH dictionary 5 "12 Jun 2015"
+.SH NAME
+dictionary \- RADIUS dictionary file
+.SH DESCRIPTION
+The master RADIUS dictionary file resides in
+\fI/etc/raddb/dictionary\fP.  It references other \fIdictionary\fP
+files located in \fI/usr/local/share/freeradius/\fP.  Each dictionary
+file contains a list of RADIUS attributes and values, which the server
+uses to map between descriptive names and on-the-wire data.  The names
+have no meaning outside of the RADIUS server itself, and are never
+exchanged between server and clients.
+.PP
+That is, editing the dictionaries will have NO EFFECT on anything
+other than the server that is reading those files.  Adding new
+attributes to the dictionaries will have NO EFFECT on RADIUS clients,
+and will not make RADIUS clients magically understand those
+attributes.  The dictionaries are solely for local administrator
+convenience, and are specific to each version of FreeRADIUS.
+.PP
+The dictionaries in \fI/usr/local/share\fP SHOULD NOT be edited unless
+you know exactly what you are doing.  Changing them will most likely
+break your RADIUS deployment.
+.PP
+If you need to add new attributes, please edit the
+\fI/etc/raddb/dictionary\fP file.  It's sole purpose is to contain
+site-local definitions that are added by the local administrator.
+
+.SH FORMAT
+Every line starting with a hash sign
+.RB (' # ')
+is treated as comment and ignored.
+.PP
+Each line of the file can contain one of the following strings:
+.TP 0.5i
+.B ATTRIBUTE name  oid  type [flags]
+Define a RADIUS attribute name to number mapping.
+
+The \fIname\fP field is a printable field, taken from various
+specifications or vendor definitions.  It is most commonly used as a
+series of words, separated by hyphens.  e.g. "User-Name".
+Vendor-specific attributes (VSAs) are prefixed by the vendor name,
+e.g. "Cisco-AVPair".  The names should be globally unique, as they are
+used as a key to look up the properties of the attribute.
+
+The \fIoid\fP field is taken from the relevant specification for that
+name.  In most cases, it is a decimal number, such as "256".  For
+certain attributes, a "dotted number" notation is used, e.g. "1.2".
+The "dotted number" notation is used only for certain attributes.
+
+The \fItype\fP field can be one of the standard types:
+
+     string       UTF-8 printable text (the RFCs call this "text")
+     octets       opaque binary data (the RFCs call this "string")
+     ipaddr       IPv4 address
+     date         Seconds since January 1, 1970 (32-bits)
+     integer      32-bit unsigned integer
+     ipv6addr     IPv6 Address
+     ipv6prefix   IPV6 prefix, with mask
+     ifid         Interface Id (hex:hex:hex:hex)
+     integer64	  64-bit unsigned integer
+
+The \fItype\fP field can be one of the following non-standard types:
+
+     ether        Ethernet MAC address
+     abinary      Ascend binary filter format
+     byte         8-bit unsigned integer
+     short        16-bit unsigned integer
+     signed       31-bit signed integer (packed into 32-bit field)
+     tlv          Type-Length-Value (allows nested attributes)
+     ipv4prefix   IPv4 Prefix as given in RFC 6572.
+
+The last (optional) field of an attribute definition are additional
+flags for that attribute, in a comma-separated list.  Previous
+versions of the server allowed these flags to include a vendor name.
+This behavior may still work, but it is deprecated, and is not
+recommended.
+
+The options are:
+
+     encrypt=#    set encryption type 1, 2, or 3.
+     has_tag      The attribute can have an RFC 2868 style tag
+
+The "encrypt" flag marks the attribute as being encrypted with one of
+three possible methods.  "1" means that the attribute is encrypted
+with the method as defined in \fIRFC2865\fP for the User-Password
+attribute.  "2" means that the password is encrypted with the method
+as defined in \fIRFC2868\fP for the Tunnel-Password attribute.  "3"
+means that the attribute is encrypted as per Ascend's definitions for
+the Ascend-Send-Secret attribute.
+
+The "has_tag" flag marks the attribute as being permitted to have a
+tag, as defined in \fIRFC2868\fP.  The purpose of the tag is to allow
+grouping of attributes for tunneled users.  See \fIRFC2868\fP for
+more details.
+
+When the server receives an encoded attribute in a RADIUS packet, it
+looks up that attribute by number in the dictionary, and uses the
+definition found there for printing diagnostic and log messages.  When
+the server sees an attribute name in a configuration file, it looks up
+that attribute by name in the dictionary, and uses the definition
+found there.
+
+.TP 0.5i
+.B VALUE attribute-name value-name number
+Define an attribute value name to number mapping, for an attribute of
+type \fIinteger\fP.  The \fIattribute-name\fP field MUST be previously
+defined by an \fIATTRIBUTE\fP entry.  The \fIvalue-name\fP field can
+be any non-space text, but is usually taken from \fIRFC2865\fP, or
+other documents..  The \fInumber\fP field is also taken from the
+relevant documents, for that name.
+
+When the server receives an encoded value in a RADIUS packet, it looks
+up the value of that attribute by number in the dictionary, and uses
+the name found there for printing diagnostic and log messages.
+.TP 0.5i
+.B VENDOR vendor-name number [format=...]
+Define a Vendor Specific Attribute encapsulation for \fIvendor-name\fP
+to \fInumber\fP.  For a list of vendor names and numbers, see
+http://www.iana.org/enterprise-numbers.txt.
+
+The "format=t,l" statement tells the server how many octets to use to
+encode/decode the vendor "type" and "length" fields in the attributes.
+The default is "format=1,1", which does not have to be specified.  For
+USR VSA's, the format is "format=4,0", for Lucent VSA's it's
+"format=2,1", and for Starent VSA's it's "format=2,2".
+
+The supported values for the number of type octets (i.e. the first
+digit) are 1, 2, and 4.  The support values for the number of length
+octets (i.e. the second digit) are 0, 1, and 2.  Any combination of
+those values will work.
+
+.TP 0.5i
+.B BEGIN-VENDOR vendor-name
+Define the start of a block of Vendor-Specific attributes.  All of the
+following \fIATTRIBUTE\fP  definitions are interpreted as being for the
+named vendor, until the block is closed by an "END-VENDOR" statement.
+
+This practice is preferred to placing the vendor name at the end of an
+\fIATTRIBUTE\fP  definition.
+
+For VSAs in the RFC 6929 "Extended vendor-specific" space, a format
+can be specified following the "vendor-name".  The format should be
+"format=Extended-Vendor-Specific-1", through
+"format=Extended-Vendor-Specific-6".  The matching "END-VENDOR" should
+just have the "vendor-name", without the format string.
+.TP 0.5i
+.B END-VENDOR vendor-name
+End a previously defined BEGIN-VENDOR block.  The "vendor-name" must match.
+.TP 0.5i
+.B $INCLUDE filename
+Include dictionary entries from the file \fIfilename\fP.  The
+\fIfilename\fP is taken as relative to the location of the file which
+is asking for the inclusion.
+.TP 0.5i
+.B BEGIN-TLV name
+This feature is supported for backwards compatibility with older
+dictionaries.  It should not be used.  The new "oid" form for defining
+the attribute number should be used instead.
+.TP 0.5i
+.B END-TLV name
+This feature is supported for backwards compatibility with older
+dictionaries.  It should not be used.  The new "oid" form for defining
+the attribute number should be used instead.
+.PP
+.SH FILES
+.I /etc/raddb/dictionary,
+.I /usr/share/freeradius/dictionary.*
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR RFC2865,
+.BR RFC2866,
+.BR RFC2868
+.BR RFC6929
diff --git a/man/man5/radiusd.conf.5 b/man/man5/radiusd.conf.5
new file mode 100644
index 0000000..3f7caa6
--- /dev/null
+++ b/man/man5/radiusd.conf.5
@@ -0,0 +1,202 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH radiusd.conf 5 "28 Jun 2013" "" "FreeRADIUS configuration file"
+.SH NAME
+radiusd.conf \- configuration file for the FreeRADIUS server
+.SH DESCRIPTION
+The \fBradiusd.conf\fP file resides in the radius database directory,
+by default \fB/etc/raddb\fP.  It defines the global configuration for
+the FreeRADIUS RADIUS server.
+.SH "CONTENTS"
+There are a large number of configuration parameters for the server.
+Most are documented in the file itself as comments.  This page
+documents only the format of the file.  Please read the
+\fBradiusd.conf\fP file itself for more information.
+
+The configuration file parser is independent of the server
+configuration.  This means that you can put almost anything into the
+configuration file.  So long as it is properly formatted, the server
+will start.
+
+When the server parses the configuration file, it looks only for those
+configurations it understands.  Extra configuration items are ignored.
+This "feature" can be (ab)used in certain interesting ways.
+.SH "FILE FORMAT"
+The file format is line-based, like many other Unix configuration
+files.  Each entry in the file must be placed on a line by itself,
+although continuations are supported.
+
+The file consists of configuration items (variable = value pairs),
+sections, and comments.
+.IP Variables
+Variables can be set via:
+
+.DS
+.br
+	name = value
+.DE
+
+Single and double-quoted strings are permitted:
+
+.DS
+.br
+	string1 = "hello world"
+.br
+	string2 = 'hello mom'
+.DE
+.IP Sections
+A section begins with a section name, followed on the same line by an
+open bracket '\fB{\fP'.  Section may contain other sections, comments, or
+variables.  Sections may be nested to any depth, limited
+only by available memory.  A section ends with a close bracket
+\'\fB}\fP', on a line by itself.
+
+.DS
+.br
+	section {
+.br
+		...
+.br
+	}
+.DE
+
+Sections can sometimes have a second name following the first one.
+The situations where this is legal depend on the context.  See the
+examples and comments in the \fBradiusd.conf\fP file for more
+information.
+
+.DS
+.br
+	section foo {
+.br
+		...
+.br
+	}
+.DE
+.IP Comments
+Any line beginning with a (\fB#\fP) is deemed to be a comment, and is
+ignored.  Comments can appear after a variable or section definitions.
+
+.DS
+.br
+	# comment
+.br
+	foo = bar # set variable 'foo' to value 'bar'
+.br
+	section {	# start of section
+.br
+	...
+.br
+	}		# end of section
+.DE
+.IP Continuations
+Long lines can be broken up via continuations, using '\\' as the last
+character of the line.  For example, the following entry:
+
+.DS
+.br
+	foo = "blah \\
+.br
+	blah \\
+.br
+	blah"
+.DE
+
+will set the value of the variable "foo" to "blah blah blah".  Any CR
+or LF is not turned into a space, but all other whitespace is
+preserved in the final value.
+.SH "REFERENCES"
+The value of a variable can reference another variable.  These
+references are evaluated when the configuration file is loaded, which
+means that there is no run-time cost associated with them.  This
+feature is most useful for turning long, repeated pieces of text into
+short ones.
+
+Variables are referenced by ${variable_name}, as in the following examples.
+
+.DS
+	foo = bar       # set variable 'foo' to value 'bar'
+.br
+	who = ${foo}    # sets variable 'who' to value of variable 'foo'
+.br
+	my = "${foo} a" # sets variable 'my' to "bar a"
+.DE
+
+If the variable exists in a section or subsection, it can be
+referenced as ${section.subsection.variable}.  Forward references are
+not allowed.  Relative references are allowed, by pre-pending the name
+with one or more period.
+
+.DS
+	blogs = ${.foo}
+
+.DE
+Will set variable \fBblogs\fP to the value of variable \fBfoo\fP,
+from the current section.
+
+.DS
+	blogs = ${..foo}
+
+.DE
+Will set variable \fBblogs\fP to the value of variable \fBfoo\fP, from the
+section which contains the current section.
+
+.DS
+	blogs = ${modules.detail.filename}
+
+.DE
+Will set variable \fBblogs\fP to the value of variable \fBfilename\fP,
+of the \fBdetail\fP module, which is in the \fBmodules\fP section of
+the configuration file.
+
+Properties of anonymous parent sections may also be referenced, currently
+\fBname\fP and \fBinstance\fP are supported.
+
+.DS
+	modules {
+		example foo {
+			file = ${.:name}
+		}
+	}
+	
+.DE
+Will set variable \fBfile\fP to the name of the containing section (example).
+
+.DS
+	modules {
+		example foo {
+			file = ${.:instance}
+		}
+	}
+	
+.DE
+Will set variable \fBfile\fP to the instance name of the containing 
+section (foo).
+
+.DS
+	modules {
+		example foo {
+			file = ${..:name}
+		}
+	}
+	
+.DE
+Will set variable \fBfile\fP to the name of the parent of the containing
+section (modules).
+.SH FILES
+/etc/raddb/radiusd.conf
+.SH "SEE ALSO"
+.BR radiusd (8)
+.BR unlang (5)
+.SH AUTHOR
+Alan DeKok <aland@freeradius.org>
diff --git a/man/man5/radrelay.conf.5 b/man/man5/radrelay.conf.5
new file mode 100644
index 0000000..db74d83
--- /dev/null
+++ b/man/man5/radrelay.conf.5
@@ -0,0 +1,146 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH radrelay.conf 5 "27 May 2005" "" "FreeRADIUS configuration file"
+.SH NAME
+radrelay.conf - configuration file for the FreeRADIUS server "radrelay" personality
+.SH DESCRIPTION
+The \fBradrelay.conf\fP file resides in the radius database directory,
+by default \fB/etc/raddb\fP.  It defines the global configuration for
+the FreeRADIUS server, when the server is operating as "radrelay".
+.SH "FILE FORMAT"
+For a detailed description of the file format, see "man radiusd.conf".
+The configuration entries are much the same for radrelay.conf, with a
+few differences as noted here.
+.SH "REPLICATION FOR BACKUPS"
+Many sites run multiple radius servers; at least one primary and one
+backup server. When the primary goes down, most NASes detect that and
+switch to the backup server.
+
+That will cause your accounting packets to go to the backup server -
+and some NASes don't even switch back to the primary server when it
+comes back up.
+
+The result is that accounting records are missed, and/or the
+administrator must jump through hoops in order to combine the
+different detail files from multiple servers. It also means that the
+session database ("radutmp", used for radwho and simultaneous use
+detection) gets out of sync.
+
+radrelay solves this issue by "relaying" packets from one server to
+another, so they both have the same set of accounting data.
+.SH "BUFFERING FOR HIGH-LOAD SERVERS"
+If the RADIUS server suddenly receives a many accounting packets,
+there may be insufficient CPU power to process them all in a timely
+manner.  This problem is especially noticeable when the accounting
+packets are going to a back-end database.
+
+Similarly, you may have one database that tracks "live" sessions, and
+another that tracks historical accounting data.  In that case,
+accessing the first database is fast, as it is small.  Accessing the
+second database many be slower, as it may contain multiple gigabytes
+of data.  In addition, writing to the first database in a timely
+manner is important, while data may be written to the second database
+with a few minutes delay, without any harm being done.
+.SH "RELAYING OF ACCOUNTING PACKETS"
+The \fBradrelay.conf\fP file controls the "radrelay" personality of
+the server, which can perform both of the functions above at the same
+time.
+.SH USAGE
+First, you should configure the main radius server to log to an extra,
+single detail file.  This may be done by adding an extra instance of
+the detail module to \fBradiusd.conf\fP:
+
+For example:
+
+.DS
+	detail radrelay-detail {
+.br
+		filename = ${radacctdir}/radrelay/detail
+.br
+		permissions = 0600
+.br
+		dir_permissions = 0755
+.br
+		locking = yes
+.br
+	}
+.br
+	...
+.br
+	accounting {
+.br
+		...
+.br
+		radrelay-detail
+.br
+		...
+.br
+	}
+.br
+.DE
+This configuration will cause accounting packets to be logged to the
+\fI${radacctdir}/radrelay/detail\fP file.  This file should not be
+rotated by standard log rotation scripts, as the \fBradrelay\fP
+program will read and rotate it.
+.SH RADRELAY.CONF EXAMPLE
+See the \fBradrelay.conf\fP file for detailed instructions on
+configuration entries, what they mean, and how to use them.
+
+To have the "radrelay" portion of the server read the above detail
+file, configure \fBradrelay.conf\fP with the following section:
+
+.DS
+.br
+	listen {
+.br
+		type = detail
+.br
+		filename = ${radacctdir}/radrelay/detail
+.br
+		max_outstanding = 100
+.br
+		identity = radrelay
+.br
+	}
+.br
+.DE
+
+The server will read the accounting packets from the detail file, and
+process them just as if it had received them from the NAS.  Therefore,
+you should configure the "accounting" section of \fBradrelay.conf\fP
+to write the accounting records to an "sql" module, or to proxy them
+to another RADIUS server.
+
+Then, start the server via the following command:
+
+$ radiusd \-n radrelay
+
+The server should start up, read the detail file, and process
+accounting packets from it.
+.SH NOTES
+The \fBradiusd.conf\fP file is not read at all when the server is
+running as radrelay.  Please edit \fBradrelay.conf\fP.
+.SH CREDITS
+The original "radrelay" program was written by Miquel van Smoorenburg
+for the Cistron radius project, and ported to FreeRADIUS by Simon
+Ekstrand.  The "radsqlrelay" was written by Kostas Kalavras.  It was
+never released as part of an official FreeRADIUS release, but served as
+a basis for the design of this implementation.
+.PP
+.SH FILES
+/etc/raddb/radrelay.conf
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.SH AUTHOR
+Alan DeKok <aland@ox.org>
diff --git a/man/man5/rlm_always.5 b/man/man5/rlm_always.5
new file mode 100644
index 0000000..383b271
--- /dev/null
+++ b/man/man5/rlm_always.5
@@ -0,0 +1,119 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_always 5 "10 January 2015" "" "FreeRADIUS Module"
+.SH NAME
+rlm_always \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_always\fP module provides a simple way to "always" return a
+value during the processing of a configuration section.
+.PP
+The main configuration item is \fIrcode\fP, which sets the return code that
+this instantiation of the module will return. The default, if none
+specified, is 'fail'.
+.PP
+The valid options for rcode are as follows:
+.RS
+.TP
+reject
+reject the user;
+.IP fail
+a failure has occurred;
+.IP ok
+success;
+.IP handled
+the request has been handled: processing should be stopped and the response
+sent;
+.IP invalid
+request is invalid;
+.IP userlock
+the user account has been locked out;
+.IP notfound
+the user account cannot be found;
+.IP noop
+no-op: nothing has happened;
+.IP updated
+the request has been updated.
+.RE
+.SH CONFIGURATION
+.PP
+.IP "rcode = <code>"
+This module will always return with the code specified, as listed in the
+table above.  If unspecified, the default is 'fail'.
+.IP "simulcount = <n>"
+If this module is used in the session{} section, the simulcount option
+simulates the user having 'n' current sessions. The default is to not
+override the number of sessions.
+.IP "mpp = <yes|no>"
+If set to yes, and this module is used in the session{} section, this
+simulates the user having multilink sessions.  The default is 'no'.
+.PP
+.SH EXAMPLE
+.PP
+.DS
+modules {
+  ...
+.br
+  # instantiate the "always" module with the name "ok"
+.br
+  always ok {
+.br
+	# return code for this instantiation is "ok":
+.br
+	rcode = ok
+.br
+  }
+.br
+  ...
+.br
+}
+.br
+
+.br
+authorize {
+  ...
+.br
+  redundant {
+     sql1          # try to find the user in sql1
+.br
+     sql2          # try to find the user in sql2
+.br
+     # the default here would be to fail, but...
+.br
+     ok            # if still not found, it's OK.
+.br
+  }
+  ...
+.br
+}
+.DE
+.SH SECTIONS
+.BR authorization,
+.BR authentication,
+.BR postauthentication,
+.BR preaccounting,
+.BR accounting,
+.BR preproxy,
+.BR postproxy
+.PP
+.SH FILES
+.I /etc/raddb/mods-available/always
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5),
+.BR unlang (5)
+.PP
+Further details of how module return codes operate can be found at <http://wiki.freeradius.org/config/Fail-over>.
+.SH AUTHOR
+Chris Parker <cparker@segv.org>, Matthew Newton
+<matthew@newtoncomputing.co.uk>.
diff --git a/man/man5/rlm_attr_filter.5 b/man/man5/rlm_attr_filter.5
new file mode 100644
index 0000000..adb6130
--- /dev/null
+++ b/man/man5/rlm_attr_filter.5
@@ -0,0 +1,145 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_attr_filter 5 "27 June 2013" "" "FreeRADIUS Module"
+.SH NAME
+rlm_attr_filter \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_attr_filter\fP module exists for filtering certain
+attributes and values in received ( or transmitted ) radius packets.
+It gives the server a flexible framework to filter the attributes we
+send to or receive from home servers or NASes.  This makes sense, for
+example, in an out-sourced dialup situation to various policy
+decisions, such as restricting a client to certain ranges of
+Idle-Timeout or Session-Timeout.
+.PP
+Filter rules are normally defined and applied on a per-realm basis,
+where the realm is anything that is defined and matched based on the
+configuration of the \fIrlm_realm\fP module.  Filter rules can
+optionally be applied using another attribute, by editing the
+\fIkey\fP configuration for this module.
+.PP
+In 2.0.1 and earlier versions, the "accounting" section filtered the
+Accounting-Request, even though it was documented as filtering the
+response.  This issue has been fixed in version 2.0.2 and later
+versions.  The "preacct" section may now be used to filter
+Accounting-Request packets.  The "accounting" section now filters
+Accounting-Response packets.  Administrators using "attr_filter" in
+the "accounting" section SHOULD move the reference to "attr_filter"
+from "accounting" to "preacct".
+.PP
+The file that defines the attribute filtering rules follows a similar
+syntax to the \fIusers\fP file.  There are a few differences however:
+.PP
+.DS
+    There are no check-items allowed other than the name of the key.
+.PP
+    There can only be a single DEFAULT entry.
+.PP
+The rules for each entry are parsed to top to bottom, and an
+attribute must pass *all* the rules which affect it in order to
+make it past the filter.  Order of the rules is important.
+The operators and their purpose in defining the rules are as
+follows:
+.TP
+.B =   
+THIS OPERATOR IS NOT ALLOWED.  If used, and warning message is
+printed and it is treated as ==
+.TP
+.B :=  
+Set, this attribute and value will always be placed in the
+output A/V Pairs.  If the attribute exists, it is overwritten.
+.TP
+.B  ==  
+Equal, value must match exactly.
+.TP
+.B  =*  
+Always Equal, allow all values for the specified attribute.
+.TP
+.B    !*  
+Never Equal, disallow all values for the specified attribute.
+( This is redundant, as any A/V Pair not explicitly permitted
+will be dropped ).
+.TP
+.B    !=  
+Not Equal, value must not match.
+.TP
+.B    >=  
+Greater Than or Equal
+.TP
+.B    <=  
+Less Than or Equal
+.TP
+.B    >   
+Greater Than
+.TP
+.B    <   
+Less Than
+.PP
+If regular expressions are enabled the following operators are
+also possible.  ( Regular Expressions are included by default
+unless your system doesn't support them, which should be rare ).
+The value field uses standard regular expression syntax.
+.PP
+.TP
+.B    =~  
+Regular Expression Equal
+.TP
+.B    !~  
+Regular Expression Not Equal
+.PP
+See the default \fI/etc/raddb/mods-config/attr_filter/\fP for working examples of
+sample rule ordering and how to use the different operators.
+.DE
+.PP
+The configuration items are:
+.IP file
+This specifies the location of the file used to load the filter rules.
+This file is used to filter the accounting response, packet before it
+is proxied, proxy response from the home server, or our response to
+the NAS.
+.IP key
+Usually %{Realm} (the default).  Can also be %{User-Name}, or other
+attribute that exists in the request.  Note that the module always
+keys off of attributes in the request, and NOT in any other packet.
+.IP relaxed
+If set to 'yes', then attributes which do not match any filter rules
+explicitly, will also be allowed. This behaviour may be overridden 
+for an individual filter block using the Relax-Filter check item.
+The default for this configuration item is 'no'.
+.PP
+.SH SECTIONS
+.IP preacct
+Filters Accounting-Request packets.
+.IP accounting
+Filters Accounting-Response packets.
+.IP pre-proxy
+Filters Accounting-Request or Access-Request packets prior to proxying
+them.
+.IP post-proxy
+Filters Accounting-Response, Access-Accept, Access-Reject, or
+Access-Challenge responses from a home server.
+.IP authorize
+Filters Access-Request packets.
+.IP post-auth
+Filters Access-Accept or Access-Reject packets.
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf
+.I /etc/raddb/mods-config/attr_filter/*
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.SH AUTHOR
+Chris Parker, cparker@segv.org
+
diff --git a/man/man5/rlm_chap.5 b/man/man5/rlm_chap.5
new file mode 100644
index 0000000..de0b8c0
--- /dev/null
+++ b/man/man5/rlm_chap.5
@@ -0,0 +1,30 @@
+.TH rlm_chap 5 "3 February 2004" "" "FreeRADIUS Module"
+.SH NAME
+rlm_chap \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_chap\fP module provides CHAP functionality.
+.PP
+This module validates a user with CHAP authentication.
+If called in Authorize, it will look for CHAP-Password
+attribute in the Access-Request and adds an Auth-Type
+attribute set to CHAP if the Config-Items list unless 
+Auth-Type has already set.
+.PP
+CHAP authentication requires access to the clear-text
+password for the user.  Standard Unix system authentication
+or passwords encrypted via crypt() are not compatible
+with CHAP.
+.PP
+.SH SECTIONS
+.BR authorization,
+.BR authentication
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.SH AUTHOR
+Chris Parker, cparker@segv.org
+
diff --git a/man/man5/rlm_counter.5 b/man/man5/rlm_counter.5
new file mode 100644
index 0000000..a8eae18
--- /dev/null
+++ b/man/man5/rlm_counter.5
@@ -0,0 +1,89 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_counter 5 "13 March 2004" "" "FreeRADIUS Module"
+.SH NAME
+rlm_counter \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_counter\fP module provides a general framework to
+allow access based on accumulated usage of a resource, such as
+total time online in a given period, total data transferred in
+a given period, etc.  This is very useful in a 'Prepaid Service'
+situation, where a user has paid for a finite amount of usage
+and should not be allowed to use more than that service.  Collection,
+monitoring, and replenishment of prepaid services are beyond the
+scope of this module.
+.PP
+The main configuration items to be aware of are:
+.IP filename
+The filename where the usage data is stored.
+.IP key
+An attribute which will be present in the Access-Request to be used as
+the 'index' value for the counter. A counter entry is tracked for
+each unique key.  The most likely key you will want to use is User-Name.
+.IP count_attribute
+An attribute which will be used to increment the counter value.  If this
+attribute is Acct-Session-Time or an integer value the counter data is
+incremented by the Attribute value.  For all other attribute types the 
+counter is incremented by one.
+.IP reset
+How frequently the counter data should be set back to 0.  Valid values for
+this variable are:
+.BR hourly,
+.BR daily,
+.BR weekly,
+.BR monthly,
+.BR or never
+Alternatively, it can be user defined, in the form: num[hdwm].  num is
+a numeric value, followed by one or none of the following letters.  h: hours,
+d: days, w: weeks, m: months.
+.IP check_name
+This defines an attribute name which will be registered by the counter module 
+and can be used to set the maximum allowed value for the counter after which 
+the user is rejected.  If Daily-Session-Time is set, you can use the following
+syntax in the Users file to set a cap of 3600 seconds ( 8 hours ):
+.PP
+.DS
+DEFAULT Max-Daily-Session := 3600
+.DE
+.PP
+.IP reply_name
+This is the name of the attribute which will contain the remaining value for
+the counter in the reply packet when the user is successfully authorized. The
+default attribute name is "Session-Timeout".
+.IP allowed_service_type
+This can be used to only apply the limitations to specific service types of
+sessions.  For example, setting this to Framed-User will only apply the counter
+module to Framed sessions, excluding other types such as Telnet or Rlogin.
+.IP cache_size
+The maximum size of the cache to be used by the module.  The default is 1000.
+.SH NOTES
+This module registers an attribute, so it should be added to the
+instantiate section, to be called on server startup.  When used
+in the authorize section, it must come after any modules which
+set the 'check_name' attribute.
+.PP
+.SH SECTIONS
+.BR instantiate,
+.BR authorize,
+.BR accounting
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.BR rlm_sqlcounter (5)
+.SH AUTHOR
+Chris Parker, cparker@segv.org
+
diff --git a/man/man5/rlm_detail.5 b/man/man5/rlm_detail.5
new file mode 100644
index 0000000..6609e16
--- /dev/null
+++ b/man/man5/rlm_detail.5
@@ -0,0 +1,89 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_detail 5 "27 June 2013" "" "FreeRADIUS Module"
+.SH NAME
+rlm_detail \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_detail\fP module writes radius packets to 'detail' files.
+It is primarily used for storing accounting information, but can be
+used in other sections to write packet details as well.
+.PP
+The file format is similar to that of the old Livingston servers, and
+many 'detail' file parsers should work with FreeRADIUS.
+.PP
+The main configuration items to be aware of are:
+.IP file
+The file name in which to store the radius packet records.  NOTE: this
+variable is run through dynamic string expansion, and can include
+FreeRADIUS variables to create a dynamic filename.
+.PP
+     %{radacctdir}/%{Client-IP-Address}/detail-%Y%m
+.PP
+     This will create one file per month, for each client.  
+     This accomplishes 'file rotation' automatically from 
+     within the server.
+.PP
+.IP permissions
+The file permissions of the file.  
+If omitted, the default is 0600.
+.IP locking
+This option is set to 'yes' or 'no'.  By default it is 'no'.  Set this
+to yes to enable file locking, which is used with the 'radrelay'
+program.
+.SH CONFIGURATION
+.PP
+.DS
+modules {
+  ...
+.br
+  detail {
+.br
+    filename = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m
+.br
+    permissions = 0600
+.br
+    dir_permissions = 0755
+.br
+    locking = no
+.br
+  }
+.br
+  ... 
+.br
+}
+  ...
+.br
+accounting {
+ ...
+.br
+ detail
+ ...
+.br
+}
+.DE
+.PP
+.SH SECTIONS
+.BR authorization,
+.BR accounting,
+.BR pre_proxy,
+.BR post_proxy,
+.BR post_authentication
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.SH AUTHORS
+Chris Parker, cparker@segv.org
diff --git a/man/man5/rlm_digest.5 b/man/man5/rlm_digest.5
new file mode 100644
index 0000000..fb99e0f
--- /dev/null
+++ b/man/man5/rlm_digest.5
@@ -0,0 +1,79 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_digest 5 "31 March 2005" "" "FreeRADIUS Module"
+.SH NAME
+rlm_digest \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_digest\fP module authenticates RADIUS Access-Request
+packets that contain Cisco SIP digest authentication attributes.  The
+module should be listed in the \fIauthorize\fP and \fIauthenticate\fP
+sections of \fIradiusd.conf\fP.
+.SH CONFIGURATION
+The digest module requires no additional configuration items.  When it
+is being used to authenticate requests, however, it does require
+access to the clear-text password for the user.  Hashed passwords are
+not acceptable, and will not work.
+.SH EXAMPLES
+Add the following lines to the top of your 'raddb/users' file:
+.PP
+.DS
+#---
+.br
+test	Auth-Type := Digest, User-Password = "test"
+.br
+	Reply-Message = "Hello, test with digest"
+.br
+#---
+.DE
+
+Once the server has been started (debugging mode is recommended),
+use '\fIradclient\fP to send the following packet to the server:
+.PP
+.DS
+$  radclient \-f digest localhost auth testing123
+.DE
+
+Where 'digest' is a file containing:
+.PP
+.DS
+  User-Name = "test",
+.br
+  Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7",
+.br
+  Digest-Realm = "testrealm",
+.br
+  Digest-Nonce = "1234abcd",
+.br
+  Digest-Method = "INVITE",
+.br
+  Digest-URI = "sip:5555551212@example.com",
+.br
+  Digest-Algorithm = "MD5",
+.br
+  Digest-User-Name = "test",
+.br
+  Message-Authenticator = ""
+.DE
+
+You should see the authentication succeed.
+
+.SH SECTIONS
+.BR authorize,
+.BR authenticate
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf,
+.I draft-sterman-aaa-sip-00.txt
+.PP
+.SH AUTHOR
+Alan DeKok <aland@ox.org>
diff --git a/man/man5/rlm_expr.5 b/man/man5/rlm_expr.5
new file mode 100644
index 0000000..313a16e
--- /dev/null
+++ b/man/man5/rlm_expr.5
@@ -0,0 +1,113 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_expr 5 "5 February 2004" "" "FreeRADIUS Module"
+.SH NAME
+rlm_expr \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_expr\fP module allows the server to perform
+limited mathematical calculations.  This module is not called
+directly in any section, it is invoked through the dynamic expansion
+of strings.
+.PP
+For example, some NAS boxes send a NAS-Port attribute
+which is a 32-bit number composed of port, card, and interface, all in
+different bytes.  To see these attributes split into pieces, you can
+have an entry in the 'users' file like:
+
+.DS
+DEFAULT
+.br
+    Vendor-Interface = `%{expr: %{NAS-Port} / (256 * 256)}`,
+.br
+    Vendor-Card = `%{expr: (%{NAS-Port} / 256) %% 256}`,
+.br
+    Vendor-Port = `%{expr: %{NAS-Port} %% 256}`
+.br
+
+.DE
+where the attributes Vendor-Interface, Vendor-Card, and Vendor-Port
+are attributes created by either you or a vendor-supplied
+dictionary.
+
+The mathematical operators supported by the expression module are:
+.TP
+.B +
+addition
+.TP
+.B -
+subtraction
+.TP
+.B /
+division
+.TP
+.B %%
+modulo remainder
+.TP
+.B *
+multiplication
+.TP
+.B &
+boolean AND
+.TP
+.B |
+boolean OR
+.TP
+.B ()
+grouping of sub-expressions
+.PP
+NOTE: The modulo remainder operator is '%%', and not '%'.  This
+is due to the '%' character being used as a special character for
+dynamic translation.
+.PP
+NOTE: These operators do NOT have precedence.  The parsing
+of the input string, and the calculation of the answer, is done
+strictly left to right.  If you wish to order the expressions, you
+MUST group them into sub-expression, as shown in the previous
+example.
+.PP
+All of the calculations are performed as unsigned 32-bit integers.
+.DE
+.SH CONFIGURATION
+.DS
+modules {
+  ...
+.br
+  expr {
+.br
+  }
+.br
+  ...
+.br
+}
+.br
+ ...
+.br
+instantiate {
+  ...
+.br
+  expr
+  ...
+.br
+}
+.SH SECTIONS
+.BR instantiate
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.SH AUTHOR
+Chris Parker, cparker@segv.org
+
diff --git a/man/man5/rlm_files.5 b/man/man5/rlm_files.5
new file mode 100644
index 0000000..52f4734
--- /dev/null
+++ b/man/man5/rlm_files.5
@@ -0,0 +1,95 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_files 5 "5 February 2004" "" "FreeRADIUS Module"
+.SH NAME
+rlm_files \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_files\fP module uses the 'users' file for accessing
+authorization information for users.  Additionally, it supports
+a 'users' file syntax to be applied to the accounting and pre-proxy
+sections.
+.PP
+The main configuration items to be aware of are:
+.IP usersfile
+The filename of the 'users' file, which is parsed during the
+authorization stage of this module.
+.IP acctusersfile
+The filename of the 'users' file, which is parsed during the
+accounting stage of this module.
+.IP preproxy_usersfile
+The filename of the 'users' file, which is parsed during the
+pre_proxy stage of this module.
+.IP compat
+This option allows FreeRADIUS to parse an old style Cistron syntax.
+The default is 'no'.  If you need to parse an old style Cistron
+file, set this option to 'cistron'.
+.IP key
+This option lets you set the attribute to use as a key to find
+entries.  The default is "%{%{Stripped-User-Name}:-%{User-Name}}".  Note
+that the key MUST supply real data.  Dynamic attributes like "Group"
+will not work, because the "Group" attribute can only be used as a
+comparison, to see if a user is in a Unix group.  It will not return
+the name of the Unix group that a user is in.
+.PP
+If you want to use groups as a key, see the \fIrlm_passwd\fP, which
+will create a real attribute that contains the group name.
+.PP
+This configuration entry enables you to have configurations that
+perform per-group checks, and return per-group attributes, where the
+group membership is dynamically defined by a previous module.  It also
+lets you do things like key off of attributes in the reply, and
+express policies like "when I send replies containing attribute
+FOO with value BAR, do more checks, and maybe send additional
+attributes".
+.SH CONFIGURATION
+.PP
+.DS
+modules {
+  ... stuff here ...
+.br
+  files {
+.br
+    usersfile = %{confdir}/users
+.br
+    acctusersfile = %{confdir}/acct_users
+.br
+    preproxy_usersfile = %{confdir}/preproxy_users
+.br
+    compat = no
+.br
+    key = %{%{Stripped-User-Name}:-%{User-Name}}
+.br
+  }
+.br
+  ... stuff here ...
+.br
+}
+.DE
+.PP
+.SH SECTIONS
+.BR authorization,
+.BR accounting,
+.BR pre_proxy
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf,
+.I /etc/raddb/users,
+.I /etc/raddb/acct_users,
+.I /etc/raddb/preproxy_users
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5),
+.BR users (5)
+.SH AUTHORS
+Chris Parker, cparker@segv.org
diff --git a/man/man5/rlm_idn.5 b/man/man5/rlm_idn.5
new file mode 100644
index 0000000..391b7d9
--- /dev/null
+++ b/man/man5/rlm_idn.5
@@ -0,0 +1,45 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_idn 5 "8 May 2013" "" "FreeRADIUS Module"
+.SH NAME
+rlm_idn \- FreeRADIUS Module
+.SH DESCRIPTION
+When instantiated, the \fIrlm_idn\fP module provides an xlat
+for performing IDNA encoding of internationalized domain names.
+Decoding and other similar encodings like plain punycode are not
+currently supported.
+.PP
+For example, the following unlang expression would evaluate to TRUE:
+
+"%{idn:fūbar.site}" == "xn--fbar-v7a.site"
+
+.PP
+Each instance of rlm_idn may take the following parameters:
+.IP use_std3_ascii_rules
+This boolean is set by default and prohibits e.g. underscores in domain names.
+.IP allow_unassigned
+This boolean is unset by default, which prohibits use of unassigned Unicode points.
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf
+.PP
+.SH REFERENCES
+RFC 3490
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.BR idna_to_ascii_8z (3)
+.SH AUTHOR
+Brian S. Julin, bjulin@clarku.edu
+
diff --git a/man/man5/rlm_mschap.5 b/man/man5/rlm_mschap.5
new file mode 100644
index 0000000..cc3a72a
--- /dev/null
+++ b/man/man5/rlm_mschap.5
@@ -0,0 +1,110 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_mschap 5 "13 March 2004" "" "FreeRADIUS Module"
+.SH NAME
+rlm_mschap \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_mschap\fP module provides MS-CHAP and MS-CHAPv2
+authentication support. 
+.PP
+This module validates a user with MS-CHAP or MS-CHAPv2 
+authentication.
+If called in Authorize, it will look for MS-CHAP Challenge/Response
+attributes in the Acess-Request and adds an Auth-Type
+attribute set to MS-CHAP in the Config-Items list unless 
+Auth-Type has already set.
+.PP
+The module can authenticate the MS-CHAP session via plain-text
+passwords (User-Password attribute), or NT passwords (NT-Password
+attribute).  The module cannot perform authentication against an NT
+domain.
+.PP
+The module also enforces the SMB-Account-Ctrl attribute.  See the
+Samba documentation for the meaning of SMB account control.  The
+module does not read Samba password files.  Instead, the fIrlm_passwd\fP
+module can be used to read a Samba password file, and supply an
+NT-Password attribute which this module can use.
+.PP
+The main configuration items to be aware of are:
+.IP authtype
+This is the string used to set the authtype.  Normally it should be
+left to the default value of MS-CHAP.
+.IP use_mppe
+Unless this is set to 'no', FreeRADIUS will add MS-CHAP-MPPE-Keys for
+MS-CHAPv1 and MS-MPPE-Recv-Key/MS-MPPE-Send-Key for MS-CHAPv2.  The
+default is 'yes'.
+.IP require_encryption
+If MPPE is enabled, setting this attribute to 'yes' will cause the
+MS-MPPE-Encryption-Policy attribute to be set to require encryption.
+The default is 'no'.
+.IP require_strong
+If MPPE is enabled, setting this attribute to 'yes' will cause the
+MS-MPPE-Encryption-Types attribute to be set to require a 128 bit key.
+The default is 'no'.
+.IP with_ntdomain_hack
+Windows clients send User-Name in the form of "DOMAIN\\User", but send the
+challenge/response based only on the User portion.  Setting this value
+to yes, enables a work-around for this error.  The default is 'no'.
+.PP
+.SH CONFIGURATION
+.DS
+modules {
+  ...
+.br
+  mschap {
+.br
+	authtype = MS-CHAP
+.br
+	use_mppe = yes	
+.br
+  }
+.br
+  ...
+.br
+}
+.br
+ ...
+.br
+authorize {
+  ...
+.br
+  mschap
+.br
+  ...
+.br
+}
+ ...
+.br
+authenticate {
+  ...
+.br
+  mschap
+.br
+  ...
+.br
+}
+.DE
+.PP
+.SH SECTIONS
+.BR authorization,
+.BR authentication
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.SH AUTHOR
+Chris Parker, cparker@segv.org
+
diff --git a/man/man5/rlm_pap.5 b/man/man5/rlm_pap.5
new file mode 100644
index 0000000..e2ad426
--- /dev/null
+++ b/man/man5/rlm_pap.5
@@ -0,0 +1,137 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_pap 5 "10 January 2015" "" "FreeRADIUS Module"
+.SH NAME
+rlm_pap \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_pap\fP module authenticates RADIUS Access-Request packets
+that contain a User-Password attribute.  The module should also be
+listed last in the \fIauthorize\fP section, so that it can set the
+Auth-Type attribute as appropriate.
+.PP
+When a RADIUS packet contains a clear-text password in the form of a
+User-Password attribute, the \fIrlm_pap\fP module may be used for
+authentication.  The module requires a "known good" password, which it
+uses to validate the password given in the RADIUS packet.  That "known
+good" password must be supplied by another module
+(e.g. \fIrlm_files\fP, \fIrlm_ldap\fP, etc.), and is usually taken
+from a database.
+.SH CONFIGURATION
+.PP
+The only configuration item is:
+.IP normalise
+The default is "yes".  This means that the module will try to
+automatically detect passwords that are hex- or base64-encoded and
+decode them back to their binary representation.  However, some clear
+text passwords may be erroneously converted.  Setting this to "no"
+prevents that conversion.
+.SH USAGE
+.PP
+The module looks for the Password-With-Header control attribute to find
+the "known good" password. The attribute value comprises the header
+followed immediately by the password data. The header is given by the
+following table.
+.PP
+.DS
+.br
+Header       Attribute           Description
+.br
+------       ---------           -----------
+.br
+{clear}      Cleartext-Password  Clear-text passwords
+.br
+{cleartext}  Cleartext-Password  Clear-text passwords
+.br
+{crypt}      Crypt-Password      Unix-style "crypt"ed passwords
+.br
+{md5}        MD5-Password        MD5 hashed passwords
+.br
+{base64_md5} MD5-Password        MD5 hashed passwords
+.br
+{smd5}       SMD5-Password       MD5 hashed passwords, with a salt
+.br
+{sha}        SHA-Password        SHA1 hashed passwords
+.br
+             SHA1-Password       SHA1 hashed passwords
+.br
+{ssha}       SSHA-Password       SHA1 hashed passwords, with a salt
+.br
+{sha2}       SHA2-Password       SHA2 hashed passwords
+.br
+{sha224}     SHA2-Password       SHA2 hashed passwords
+.br
+{sha256}     SHA2-Password       SHA2 hashed passwords
+.br
+{sha384}     SHA2-Password       SHA2 hashed passwords
+.br
+{sha512}     SHA2-Password       SHA2 hashed passwords
+.br
+{ssha224}    SSHA2-224-Password  SHA2 hashed passwords, with a salt
+.br
+{ssha256}    SSHA2-256-Password  SHA2 hashed passwords, with a salt
+.br
+{ssha384}    SSHA2-384-Password  SHA2 hashed passwords, with a salt
+.br
+{ssha512}    SSHA2-512-Password  SHA2 hashed passwords, with a salt
+.br
+{nt}         NT-Password         Windows NT hashed passwords
+.br
+{nthash}     NT-Password         Windows NT hashed passwords
+.br
+{md4}        NT-Password         Windows NT hashed passwords
+.br
+{x-nthash}   NT-Password         Windows NT hashed passwords
+.br
+{ns-mta-md5} NS-MTA-MD5-Password Netscape MTA MD5 hashed passwords
+.br
+{x- orcllmv} LM-Password         Windows LANMAN hashed passwords
+.br
+{X- orclntv} NT-Password         Windows NT hashed passwords
+.DE
+
+The module tries to be flexible when handling the various password
+formats.  It will automatically handle Base-64 encoded data, hex
+strings, and binary data, and convert them to a format that the server
+can use.
+.PP
+If there is no Password-With-Header attribute, the module looks for one
+of the Cleartext-Password, NT-Password, Crypt-Password, etc. attributes
+as listed in the above table. These attributes should contain the
+relevant format password directly, without the header prefix.
+.PP
+Only one control attribute should be set, otherwise behaviour is
+undefined as to which one is used for authentication.
+.SH NOTES
+.PP
+It is important to understand the difference between the User-Password
+and Cleartext-Password attributes.  The Cleartext-Password attribute
+is the "known good" password for the user.  Simply supplying the
+Cleartext-Password to the server will result in most authentication
+methods working.  The User-Password attribute is the password as typed
+in by the user on their private machine.  The two are not the same,
+and should be treated very differently.  That is, you should generally
+not use the User-Password attribute anywhere in the RADIUS
+configuration.
+.SH SECTIONS
+.BR authorize
+.BR authenticate
+.PP
+.SH FILES
+.I /etc/raddb/mods-available/pap
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5)
+.SH AUTHOR
+Alan DeKok <aland@freeradius.org>
+
diff --git a/man/man5/rlm_passwd.5 b/man/man5/rlm_passwd.5
new file mode 100644
index 0000000..5a9ac7b
--- /dev/null
+++ b/man/man5/rlm_passwd.5
@@ -0,0 +1,136 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_passwd 5 "20 January 2015" "" "FreeRADIUS Module"
+.SH NAME
+rlm_passwd \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_passwd\fP module provides authorization via files similar
+in format to /etc/passwd.
+.PP
+This module allows you to retrieve any account information from any
+files with passwd-like format (/etc/passwd, /etc/group,
+smbpasswd, .htpasswd, etc). Every field of the file may be mapped to
+a RADIUS attribute, with one of the fields used as a key.
+.PP
+The module reads the file when it initializes, and caches the data in
+memory.  This makes it very fast, even for files with thousands of
+lines. To re-read the file the module will need to be reloaded with
+\fIradmin(8)\fP, or the server will need to be sent a SIGHUP, as
+dynamic updates are not supported.
+.PP
+.SH CONFIGURATION
+The configuration item(s):
+.IP allow_multiple_keys
+If set to 'yes', and more than one record in file matches the request,
+then the attributes from all records will be used. If set to 'no' (the
+default) the module will warn about duplicated records.
+.IP delimiter\ =\ ":"
+The character to use as a delimiter between fields.  The default is
+":"
+.IP filename
+The path to the file.
+.IP format
+The format of the fields in the file, given as an example line from
+the file, with the content of the fields as the RADIUS attributes
+which the fields map to. The fields are separated by the ':' character
+in the configuration (no matter what is configured for the 'delimiter'
+option).
+.IP hash_size
+The size of the hash table. A larger value means less probability of a
+collision so records will be found faster, at the expense of greater
+memory usage. Having a hash_size in the range of 30-100% of the number
+of passwd file records is reasonable.
+.IP ignore_empty
+When set to "yes", the default, empty fields in the input will be
+skipped and the RADIUS attribute will not be added.  By setting this
+value to "no", all attributes in the format list will always be added,
+even if they have no value.
+.IP ignore_nislike
+If set to 'yes', then all records from the file beginning with the '+'
+sign will be ignored.  The default is 'no'.
+.PP
+.SH FORMAT
+The \fIformat\fP option controls how lines are read from the file, and
+which fields are mapped to which RADIUS attributes.
+.PP
+The key field is the field being searched for within the file. It is
+normally signified by being preceded with a '*' character, which
+indicates that the field has only one key, like the /etc/passwd file.
+The key field may instead be preceded with '*,', which indicates that
+the field has multiple possible comma-separated keys, such as when
+searching the /etc/group file.
+.PP
+The other fields signify RADIUS attributes. By default they will be
+added as a control attribute list.
+.PP
+To add an attribute to the RADIUS request (as though it had been sent
+by the NAS), prefix the attribute name in the "format" string with the
+\(aq~' character.
+.PP
+To add an attribute to the RADIUS reply (to be sent back to the NAS),
+prefix the attribute name in the "format" string with the '='
+character.
+.PP
+.SH EXAMPLES
+.DS
+format = "*User-Name:Crypt-Password:"
+.DE
+.IP
+For a file the looks similar to /etc/passwd. The first field,
+User-Name, is the key to look up in the file. When the record is
+found, a control attribute, 'Crypt-Password', will be added with the
+contents of the second field. (Note this will not work with shadow
+passwords.)
+.PP
+.DS
+format = "My-Group:::*,User-Name"
+.DE
+.IP
+Parse a file similar to the /etc/group file.  An entry matches a
+request when the name in a User-Name attribute exists in the
+comma-separated list of a line in the file.  When an entry matches, 
+a "My-Group" attribute will be created and added to the control
+items for the request.  The value of that attribute will be taken from
+the first field of the matching line in the file.
+.IP
+The ":::" in the format string means that there are extra two fields
+in the line, in between the group name and list of user names.  Those
+fields do not map to any RADIUS attribute, and are therefore ignored.
+.IP
+For this example to work in practice, you will have to add the
+My-Group attribute to the dictionary file.  See \fIdictionary(5)\fP
+for details on how this may be done.
+.PP
+.DS
+format = "~My-Group:::*,User-Name"
+.DE
+.IP
+Similar to the previous entry, except the My-Group attribute is added
+to the request, as though it was sent by the NAS.
+.PP
+.SH SECTIONS
+.BR authorize
+.PP
+.SH FILES
+.I /etc/raddb/mods-available/passwd
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5),
+.BR radmin (8),
+.BR dictionary (5),
+.BR rlm_unix (5)
+.SH AUTHOR
+Alan DeKok <aland@freeradius.org>, Matthew Newton
+<matthew@newtoncomputing.co.uk>.
+
diff --git a/man/man5/rlm_realm.5 b/man/man5/rlm_realm.5
new file mode 100644
index 0000000..8b8237a
--- /dev/null
+++ b/man/man5/rlm_realm.5
@@ -0,0 +1,94 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_realm 5 "14 March 2004" "" "FreeRADIUS Module"
+.SH NAME
+rlm_realm \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_realm\fP module parses the User-Name attribute into a
+User section and a Realm section.  This is used primarily in a
+proxy situation, however, Realms can also be used locally to provide
+different service profiles based on the Realm being used.
+.PP
+The main configuration items to be aware of are:
+.IP format
+This can be either 'prefix' or 'suffix'.  It specifies whether the
+Realm is before or after the User portion in the User-Name string.
+.IP delimiter
+A single character in quotes, which is used as the delimiting
+character that separates the Realm and User sections of the string.
+.IP ignore_default
+This is set to either 'yes' or 'no'.  If set to 'yes', this will 
+prevent the module instance from matching a realm against the DEFAULT
+entry.  This may be useful if you have multiple realm module instances.
+The default is 'no'.
+.IP ignore_null
+This is set to either 'yes' or 'no'.  If set to 'yes', this will 
+prevent the module instance from matching a realm against the NULL
+entry.  This may be useful if you have multiple realm module instances.
+The default is 'no'.
+.PP
+This module parses the realm from the User-Name attribute according
+to the instance configuration, and then performs a lookup to find a
+matching realm in the '/etc/raddb/proxy.conf' file.  Depending on the
+configuration of the Realm as matched in the file, the username may
+be rewritten in a 'stripped' format, or with the Realm portion
+removed.  In either case, a Realm attribute is created and added to
+the packet on a match, which can be used by other modules.
+.SH CONFIGURATION
+.PP
+.DS
+modules {
+  ... stuff here ...
+.br
+.br
+  # useranme@realm syntax
+.br
+  realm suffix {
+.br
+    format = suffix
+.br
+    delimiter = "@"
+.br
+  }
+.br
+.br
+   # realm/username syntax
+.br
+   realm prefix {
+.br
+    format = prefix
+.br
+    delimiter = "/"
+.br
+  }
+.br
+.br
+  ... stuff here ...
+.br
+}
+.DE
+.PP
+.SH SECTIONS
+.BR authorization,
+.BR pre-accounting
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf,
+.I /etc/raddb/proxy.conf
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5),
+.BR proxy.conf (5)
+.SH AUTHORS
+Chris Parker, cparker@segv.org
diff --git a/man/man5/rlm_sql.5 b/man/man5/rlm_sql.5
new file mode 100644
index 0000000..f0c42b5
--- /dev/null
+++ b/man/man5/rlm_sql.5
@@ -0,0 +1,152 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_sql 5 "5 February 2004" "" "FreeRADIUS Module"
+.SH NAME
+rlm_sql \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_sql\fP module provides an SQL interface to retrieve
+authorization information and store accounting information.  It can be
+used in conjunction with, or in lieu of the files and detail modules.
+The SQL module has drivers to support the following SQL databases:
+.PP
+.DS
+.br
+     db2
+.br
+     iodbc
+.br
+     mysql
+.br
+     oracle
+.br
+     postgresql
+.br
+     sybase
+.br
+     unixodbc
+.br
+.DE
+.PP
+Due to the size of the configuration variables, the sql module is
+usually configured in a separate file, which is included in the main
+radiusd.conf via an include directive.
+.PP
+The main configuration items to be aware of are:
+.IP driver
+This variable specifies the driver to be loaded.
+.IP server
+.IP login
+.IP password
+These specify the servername, username, and password the module will
+use to connect to the database.
+.IP radius_db
+The name of the database where the radius tables are stored.
+.IP acct_table1
+.IP acct_table2
+These specify the tables names for accounting records.  acct_table1
+specifies the table where Start records are stored.  acct_table2
+specifies the table where Stop records are stored.  In most cases,
+this should be the same table.
+.IP postauth_table
+The name of the table to store post-authentication data.
+.IP authcheck_table
+.IP authreply_table
+The tables where individual Check-Items and Reply-Items are stored.
+.IP groupcheck_table
+.IP groupreply_table
+The tables where group Check-Items and Reply-Items are stored.
+.IP usergroup_table
+The table where username to group relationships are stored.
+.IP deletestalesessions
+This option is set to 'yes' or 'no'.  If you are doing
+Simultaneous-Use checking, and this is set to yes, stale sessions (
+defined as sessions for which a Stop record was not received ) will be
+cleared.
+.IP logfile
+This option is useful for debugging sql problems.  If logfile is set
+then all sql queries for the containing section are written to the
+file specified.  This is useful for debugging and bulk inserts.
+.IP num_sql_socks
+The number of sql connections to make to the database.
+.IP connect_failure_retry_delay
+The number of seconds to wait before attempting to reconnect to a
+failed database connection.
+.IP sql_user_name
+This is the definition of the SQL-User-Name attribute.  This is set
+once, so that you can use %{SQL-User-Name} in the SQL queries, rather
+than the nested username substitution.  This ensures that Username is
+parsed consistently for all SQL queries executed.
+.IP default_user_profile
+This is the default profile name that will be applied to all users if
+set.  This is not set by default.
+.IP query_on_not_found
+This option is set to 'yes' or 'no'.  If set to yes, then the default
+user profile is returned if no specific match was found for the user.
+.IP authorize_check_query
+.IP authorize_reply_query
+These queries are run during the authorization stage to extract the
+user authorization information from the ${authcheck_table} and
+${authreply_table}.
+.IP authorize_group_check_query
+.IP authorize_group_reply_query
+These queries are run during the authorization stage to extract the
+group authorization information from the ${groupcheck_table} and
+${groupreply_table}.
+.IP accounting_onoff_query
+The query to be run when receiving an Accounting On or Accounting Off
+packet.
+.IP accounting_update_query
+.IP accounting_update_query_alt
+The query to be run when receiving an Accounting Update packet.  If the
+primary query fails, the alt query is run.
+.IP accounting_start_query
+.IP accounting_start_query_alt
+The query to be run when receiving an Accounting Start packet.  If the
+primary query fails, the alt query is run.
+.IP accounting_stop_query
+.IP accounting_stop_query_alt
+The query to be run when receiving an Accounting Stop packet.  If the
+primary query fails, the alt query is run.
+.IP simul_count_query
+The query to be run to return the number simultaneous sessions for the
+purposes of limiting Simultaneous Use.
+.IP simul_verify_query
+The query to return the detail information needed to confirm that all
+suspected connected sessions are valid, and are not stale sessions.
+.IP group_membership_query
+The query to run to check user group membership.
+.IP postauth_query
+The query to run during the post-authentication stage.
+.SH CONFIGURATION
+.PP
+Due to the size of the configuration for this module, it is not
+included in this manual page.  Please review the supplied
+configuration files for example queries and configuration details.
+.SH SECTIONS
+.BR authorization,
+.BR accounting,
+.BR checksimul,
+.BR post-authentication
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf,
+.I /etc/raddb/sql.conf,
+.I /etc/raddb/sql/<DB>/dialup.conf,
+.I /etc/raddb/sql/<DB>/schema.sql,
+.BR
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5),
+.SH AUTHORS
+Chris Parker, cparker@segv.org
diff --git a/man/man5/rlm_unix.5 b/man/man5/rlm_unix.5
new file mode 100644
index 0000000..38668e0
--- /dev/null
+++ b/man/man5/rlm_unix.5
@@ -0,0 +1,66 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH rlm_unix 5 "17 February 2005" "" "FreeRADIUS Module"
+.SH NAME
+rlm_unix \- FreeRADIUS Module
+.SH DESCRIPTION
+The \fIrlm_unix\fP module reads crypt(3) passwords from the system
+password file, and allows the server to use them for authentication.
+The module also provides FreeRADIUS an interface into a radwtmp file
+(used by "radlast") when added to the accounting section.
+.PP
+The \fIrlm_unix\fP module should be listed in the
+"authenticate" section.  Please see the default \fIradiusd.conf\fP
+shipped with the server for an example of the correct usage of this
+module.
+.PP
+As of FreeRADIUS 1.1.0, the module no longer reads, or caches
+/etc/passwd, /etc/shadow, or /etc/group.  If you wish to cache those
+files, see \fIrlm_passwd\fP.  Most, if not all, configurations should
+not need those files to be cached.
+.PP
+The main configuration items to be aware of are:
+.IP radwtmp
+The path to the system wtmp file to be used for keeping the database
+of online users as read by the 'radlast' program.
+.SH CONFIGURATION
+.PP
+.DS
+modules {
+  ...
+.br
+  unix {
+.br
+    radwtmp = ${logdir}/radwtmp
+.br
+  }
+.br
+  ...
+.br
+}
+.DE
+.PP
+.SH SECTIONS
+.BR authentication,
+.BR accounting
+.PP
+.SH FILES
+.I /etc/raddb/radiusd.conf,
+.PP
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR radiusd.conf (5),
+.BR rlm_passwd (5),
+.BR radlast (1)
+.SH AUTHORS
+Chris Parker, cparker@segv.org
diff --git a/man/man5/unlang.5 b/man/man5/unlang.5
new file mode 100644
index 0000000..63f5570
--- /dev/null
+++ b/man/man5/unlang.5
@@ -0,0 +1,900 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH unlang 5 "16 February 2021" "" "FreeRADIUS Processing un-language"
+.SH NAME
+unlang \- FreeRADIUS Processing un\-language
+.SH DESCRIPTION
+FreeRADIUS supports a simple processing language in its configuration
+files.  We call it an "un-language" because the intention is NOT to
+create yet another programming language.  If you need something more
+complicated than what is described here, we suggest using the Perl or
+Python modules rlm_perl, or rlm_python.
+
+The goal of the language is to allow simple policies to be written
+with minimal effort.  Those policies are then applied when a request
+is being processed.  Requests are processed through virtual servers
+(including the default one), in the sections titled "authorize",
+"authenticate", "post-auth", "preacct", "accounting", "pre-proxy",
+"post-proxy", and "session".
+
+These policies cannot be used in any other part of the configuration
+files, such as module or client configuration.
+.SH KEYWORDS
+The keywords for the language are a combination of pre-defined
+keywords, and references to loadable module names.  We document only
+the pre-defined keywords here.
+
+Subject to a few limitations described below, any keyword can appear
+in any context.  The language consists of a series of entries, each
+one line.  Each entry begins with a keyword.  Entries are
+organized into lists.  Processing of the language is line by line,
+from the start of the list to the end.  Actions are executed
+per-keyword.
+.IP module-name[.section-name]
+A reference to the named module.  When processing reaches this point,
+the pre-compiled module is called.  The module may succeed or fail,
+and will return a status to "unlang" if so.  This status can be tested
+in a condition.  See the "Simple Conditions" text in the CONDITIONS
+section, and MODULE RETURN CODES, below.
+If a section-name is provided, it will cause the module to execute 
+as if it were listed in the named section.
+
+.DS
+	chap  # call the CHAP module
+.br
+	sql   # call the SQL module
+.br
+	...
+.DE
+.IP if
+.br
+Checks for a particular condition.  If true, the block after the
+condition is processed.  Otherwise, the block is ignored.  See
+CONDITIONS, below, for documentation on the format of the conditions.
+
+.DS
+	if (condition) {
+.br
+		...
+.br
+	}
+.DE
+.IP else
+.br
+Define a block to be executed only if the previous "if" condition
+returned false.
+
+.DS
+	else {
+.br
+		...
+.br
+	}
+.DE
+.IP elsif
+.br
+Define a block to be executed only if the previous "if" condition
+returned false, and if the specified condition evaluates to true.
+
+.DS
+	elsif (condition) {
+.br
+		...
+.br
+	}
+.DE
+.IP foreach
+.br
+Loops over values of an attribute, running the block for each value.
+The return value of the block is the return value of the last
+statement executed.  The loop can be exited early by using the "break"
+keyword.  Unlike other languages, "break" here means "exit the loop at
+the next iteration", not "exit the loop now".  The result is that any
+statements after the "break" keyword will still be executed.  We
+recommend using "break" only when it is the last statement in a
+"foreach" block.
+
+Inside of the "foreach" block, the attribute which is being looped
+over can be referenced as "Foreach-Variable-#".  Where "#" is the
+depth of the loop, starting at "0".  e.g. "Foreach-Variable-0".  The
+loops can be nested up to eight (8) deep, though this is not
+recommended.
+
+.DS
+	foreach &Attribute-Reference {
+.br
+		...
+.br
+	}
+.DE
+.IP switch
+.br
+A "switch" statement takes one argument, and contains a series of
+"case" statements.  When a "switch" statement is encountered, the
+argument from the "switch" is evaluated in turn against the argument
+from each "case" statement.  The first "case" statement which matches
+is executed.  All other "case" statements are ignored.  A default
+"case" statement can be defined, by omitting its argument.
+
+If the argument is a double quoted string (e.g. "%{exec:1 + 2}", it is
+expanded as described in the DATA TYPES section, below.  The match is
+then performed on the string returned from the expansion.  If the
+argument is an attribute reference (e.g. &User-Name), then the match
+is performed on the value of that attribute.  Otherwise, the argument
+is taken to be a literal string, and matching is done via simple
+comparison.
+
+No statement other than "case" can appear in a "switch" block.
+
+.DS
+	switch <argument> {
+.br
+		...
+.br
+	}
+.DE
+.IP case
+.br
+Provides a place-holder which matches the argument of a parent
+"switch" statement.
+
+A "case" statement cannot appear outside of a "switch" block.
+
+If the argument is a double quoted string (e.g. "%{exec:1 + 2}", it is
+expanded as described in the DATA TYPES section, below.  The match is
+then performed on the string returned from the expansion.  If the
+argument is an attribute reference (e.g. &User-Name), then the match
+is performed on the value of that attribute.  Otherwise, the argument
+is taken to be a literal string, and matching is done via simple
+comparison.
+
+.DS
+	case <argument> {
+.br
+		...
+.br
+	}
+.DE
+A default entry can be defined by omitting the argument, as given
+below.  This entry will be used if no other "case" entry matches.
+Only one default entry can exist in a "switch" section.
+
+.DS
+	case {
+.br
+		...
+.br
+	}
+.DE
+.IP update
+.br
+Update a particular attribute list, based on the attributes given in
+the current block.
+
+.DS
+	update <list> {
+.br
+		&Attribute-Reference = value
+.br
+		...
+.br
+	}
+.DE
+The <list> can be one of "request", "reply", "proxy-request",
+"proxy-reply", "coa", "disconnect", "session-state", or "control".  As
+of Version 3, the <list> can be omitted, in which case "request" is
+assumed.
+
+The "control" list is the list of attributes maintained internally by
+the server that controls how the server processes the request.  Any
+attribute that does not go in a packet on the network will generally
+be placed in the "control" list.
+
+For EAP methods with tunneled authentication sessions (i.e. PEAP and
+EAP-TTLS), the inner tunnel session can also reference
+"outer.request", "outer.reply", and "outer.control".  Those references
+allow you to address the relevant list in the outer tunnel session.
+
+The "coa" and "disconnect" sections can only be used when the server
+receives an Access-Request or Accounting-Request.  Use "request" and
+"reply" instead of "coa" when the server receives a CoA-Request or
+Disconnect-Request packet.
+
+Adding one or more attributes to either of the "coa" or "disconnect"
+list causes server to originate a CoA-Request or Disconnect-Request
+packet.  That packet is sent when the current Access-Request or
+Accounting-Request has been finished, and a reply sent to the NAS.
+See raddb/sites-available/originate-coa for additional information.
+
+The "session-state" list is primarily used for EAP.  Attributes put
+into the "session-state" list are saved for the next packet in the
+session.  They are automatically retrieved when the next packet is
+received.
+
+The only contents permitted in an "update" section are attributes and
+values.  The contents of the "update" section are described in the
+ATTRIBUTE REFERENCE and ATTRIBUTE ASSIGNMENT sections below.
+.IP redundant
+This section contains a simple list of modules.  The first module is
+called when the section is being processed.  If the first module
+succeeds in its operation, then the server stops processing the
+section, and returns to the parent section.
+
+If, however, the module fails, then the next module in the list is
+tried, as described above.  The processing continues until one module
+succeeds, or until the list has been exhausted.
+
+Redundant sections can contain only a list of modules, and cannot
+contain keywords that perform conditional operations (if, else, etc)
+or update an attribute list.
+
+.DS
+	redundant {
+.br
+		sql1	# try this
+.br
+		sql2	# try this only if sql1 fails.
+.br
+		...
+.br
+	}
+.DE
+.IP load-balance
+This section contains a simple list of modules.  When the section is
+entered, one module is chosen at random to process the request.  All
+of the modules in the list should be the same type (e.g. ldap or sql).
+All of the modules in the list should behave identically, otherwise
+the load-balance section will return different results for the same
+request.
+
+Load-balance sections can contain only a list of modules, and cannot
+contain keywords that perform conditional operations (if, else, etc)
+or update an attribute list.
+
+.DS
+	load-balance {
+.br
+		ldap1	# 50% of requests go here
+.br
+		ldap2	# 50% of requests go here
+.br
+	}
+.DE
+In general, we recommend using "redundant-load-balance" instead of
+"load-balance".
+.IP redundant-load-balance
+This section contains a simple list of modules.  When the section is
+entered, one module is chosen at random to process the request.  If
+that module succeeds, then the server stops processing the section.
+If, however, the module fails, then one of the remaining modules is
+chosen at random to process the request.  This process repeats until
+one module succeeds, or until the list has been exhausted.
+
+All of the modules in the list should be the same type (e.g. ldap or
+sql).  All of the modules in the list should behave identically,
+otherwise the load-balance section will return different results for
+the same request.
+
+Load-balance sections can contain only a list of modules, and cannot
+contain keywords that perform conditional operations (if, else, etc)
+or update an attribute list. Please see raddb/radiusd.conf 
+"instantiate" section for more configuration examples.
+
+.DS
+	redundant-load-balance {
+.br
+		ldap1	# 50%, unless ldap2 is down, then 100%
+.br
+		ldap2	# 50%, unless ldap1 is down, then 100%
+.br
+	}
+.DE
+.IP return
+.br
+Returns from the current top-level section, e.g. "authorize" or
+"authenticate".  This keyword is mainly used to avoid layers of nested
+"if" and "else" statements.
+
+.DS
+	authorize {
+.br
+		if (...) {
+.br
+			...
+.br
+			return
+.br
+		}
+.br
+		...  # this is never reached when the "if"
+.br
+		...  # statement is executed
+.br
+	}
+.DE
+.SH ATTRIBUTE REFERENCES
+
+Attributes may be referenced via the following syntax:
+.DS
+	&Attribute-Name
+	&Attribute-Name:TAG
+	&Attribute-Name[NUM]
+	&<list>:Attribute-Name
+	&<list>:Attribute-Name:TAG[NUM]
+.DE
+Where <list> is one of "request", "reply", "control", "proxy-request",
+"proxy-reply", or "outer.request", "outer.reply", "outer.control",
+"outer.proxy-request", or "outer.proxy-reply". just as with the
+"update" section, above.  The "<list>:" prefix is optional, and if
+omitted, is assumed to refer to the "request" list.
+
+The TAG portion is a decimal integer between 1 and 31.  Please see RFC
+2868 for more information about tags.  Tags can only be used for
+attributes which are marked in the dictionary as "has_tag".
+
+The NUM portion is used when there are multiple attributes of the same
+name in a list.  The "Attribute-Name" reference will return the first
+attribute.  Using an array offset allows the policy to refer to the
+second and subsequent attributes.
+
+If '*' is used in the NUM portion, it evaluates to all instances of
+the attribute in the request.
+
+If 'n' is used in the NUM portion, it evaluates to the last instance
+of the attribute in the request.
+
+When an attribute name is encountered, the given list is examined for
+an attribute of the given name.  Some examples are:
+.DS
+	User-Name
+.br
+	request:User-Name # same as above
+.br
+	reply:User-Name
+.br
+	Tunnel-Password:1
+.br
+	Cisco-AVPAir[2]
+.br
+	outer.request:User-Name # from inside of a TTLS/PEAP tunnel
+.DE
+Note that unlike C, there is no way to define new attributes at
+run-time.  They MUST be declared in a dictionary file, and loaded when
+the server starts.
+
+All attributes are defined in the dictionaries that accompany the
+server.  These definitions define only the name and type, and do not
+define the value of the attribute.  When the server receives a packet,
+it uses the packet contents to look up entries in the dictionary, and
+instantiates attributes with a name taken from the dictionaries, and a
+value taken from the packet contents.  This process means that if an
+attribute does not exist, it is usually because it was not contained
+in a packet that the server received.
+
+Once the attribute is instantiated, it is added to a list.  It can
+then be referenced, updated, replaced, etc.
+
+.SH CONDITIONS
+The conditions are similar to C conditions in syntax, though
+quoted strings are supported, as with the Unix shell.
+.IP Simple
+conditions
+.br
+.DS
+	(foo)
+.DE
+Evaluates to true if 'foo' is a non-empty string (single quotes, double
+quotes, or back-quoted).  Also evaluates to true if 'foo' is a
+non-zero number.  Note that the language is poorly typed, so the
+string "0000" can be interpreted as a numerical zero.  This issue can
+be avoided by comparing strings to an empty string, rather than by
+evaluating the string by itself.
+
+If the word 'foo' is not a quoted string, then it can be taken as a
+reference to a named attribute.  See "Referencing attribute lists",
+below, for examples of attribute references.  The condition evaluates
+to true if the named attribute exists.
+
+Otherwise, if the word 'foo' is not a quoted string, and is not an
+attribute reference, then it is interpreted as a reference to a module
+return code.  The condition evaluates to true if the most recent
+module return code matches the name given here.  Valid module return
+codes are given in MODULE RETURN CODES, below.
+.IP Negation
+.DS
+	(!foo)
+.DE
+Evaluates to true if 'foo' evaluates to false, and vice-versa.
+.PP
+Short-circuit operators
+.RS
+.br
+.DS
+	(foo || bar)
+.br
+	(foo && bar)
+.DE
+"&&" and "||" are short-circuit operators.  "&&" evaluates the first
+condition, and evaluates the second condition if and only if the
+result of the first condition is true.  "||" is similar, but executes
+the second command if and only if the result of the first condition is
+false.
+.RE
+.IP Comparisons
+.DS
+	(foo == bar)
+.DE
+Compares 'foo' to 'bar', and evaluates to true if the comparison holds
+true.  Valid comparison operators are "==", "!=", "<", "<=", ">",
+">=", "=~", and "!~", all with their usual meanings.  The operators
+":=", "^=" and "=" are assignment operators, and are not allowed for
+comparisons.
+
+The operators "<", "<=", ">", and ">=" are also allowed for checking
+that an IP address is contained within a network.  For example:
+.DS
+	if (<ipaddr>192.0.2.1 < 192.0.2.0/24) {
+.DE
+This comparison succeeds, because the address 192.0.2.1 is contained
+within the network 192.0.2.0/24.
+.RE
+.IP "Attribute Comparisons"
+When doing attribute comparisons, the data type of the attribute is
+used to determine the data type of the right-hand side argument.
+.DS
+	(&User-Name == "foo")
+.DE
+Compares the value of the User-Name attribute to the string 'foo', and
+evaluates to true if the comparison holds true.
+
+Similarly,
+.DS
+	(&Framed-IP-Address == 192.0.2.1)
+.DE
+Compares the value of the Framed-IP-Address attribute to the IP
+address 192.0.2.1.  This IP address does not need to be quoted.
+.RE
+.IP "Inter-Attribute Comparisons"
+.DS
+	(&User-Name == &Filter-Id)
+.DE
+Compares the value of the User-Name attribute to the contents of the
+Filter-Id attribute, and evaluates to true if the comparison holds
+true.  Unlike the previous example, this comparison is done in a
+type-safe way.  For example, comparing the IP addresses 1.2.3.4 and
+127.0.0.1 as strings will return different results than comparing them
+as IP addresses.
+
+The "&" character in the condition means that the comparison "refers"
+to the Filter-Id attribute.  If left off, it means that the User-Name
+attribute is compared to the literal string "Filter-Id".
+
+Where the left-hand side is an attribute, the "&" can be omitted.
+However, it is allowed for backwards compatibility.  e.g. The comparison
+"(&User-Name == &Filter-Id)" is equivalent to the example above.
+
+We recommend using attribute references instead of printing
+attributes to a string, e.g. (User-Name == "%{Filter-Id}").
+Attribute references will be faster and more efficient.
+
+The conditions will check only the first occurrence of an attribute.
+If there is more than one instance of an attribute, the following
+syntax should be used:
+
+.DS
+	(&Attribute-Name[*] == "foo")
+.DE
+Using the "[*]" syntax means that it checks all of the instances of
+the named attribute.  If one attribute matches, the condition
+succeeds.  If none match, the condition fails.
+
+.RE
+.IP Casts
+.DS
+	(<type>foo == bar)
+.DE
+The left-hand-side of a condition can be "cast" to a specific data
+type.  The data type must be one which is valid for the dictionaries.
+e.g. "integer", "ipaddr", etc.
+
+The comparison is performed in a type-safe way, as with
+"Inter-Attribute Comparisons", above.  Both sides of the condition are
+parsed into temporary attributes, and the attributes compared via
+type-specific methods.  The temporary attributes have no other effect,
+and are not saved anywhere.
+
+Casting allows conditions to perform type-specific comparisons.  In
+previous versions of the server, the data would have to be manually
+placed into an intermediate attribute (or attributes), and then the
+attribute (or attributes) compared.  The use of a cast allows for
+simpler policies.
+
+Casts are allowed only on the left-hand side argument of a condition.
+.PP
+Conditions may be nested to any depth, subject only to line length
+limitations (8192 bytes).
+.SH DATA TYPES
+There are only a few data types supported in the language.  Reference
+to attributes, numbers, and strings.  Any data type can appear in
+stand-alone condition, in which case they are evaluated as described
+in "Simple conditions", above.  They can also appear (with some
+exceptions noted below) on the left-hand or on the right-hand side of
+a comparison.
+.IP numbers
+Numbers are composed of decimal digits.  Floating point, hex, and
+octal numbers are not supported.  The maximum value for a number is
+machine-dependent, but is usually 32-bits, including one bit for a
+sign value.
+.PP
+word
+.RS
+Text that is not enclosed in quotes is interpreted differently
+depending on where it occurs in a condition.  On the left hand side of
+a condition, it is interpreted as a reference to an attribute.  On the
+right hand side, it is interpreted as a simple string, in the same
+manner as a single-quoted string.
+
+Using attribute references permits limited type-specific comparisons,
+as seen in the examples below.
+
+.DS
+	if (&User-Name == "bob") {
+.br
+		...
+.br
+	if (&Framed-IP-Address > 127.0.0.1) {
+.br
+		...
+.br
+	if (&Service-Type == Login-User) {
+.DE
+.RE
+.IP """strings"""
+.RS
+Double-quoted strings are expanded by inserting the value of any
+attributes (see ATTRIBUTE REFERENCES, below) before being evaluated.  If
+the result is a number it is evaluated in a numerical context.
+
+String length is limited by line-length, usually about 8000
+characters.  A double quote character can be used in a string via
+the normal back-slash escaping method.  ("like \\"this\\" !")
+.RE
+.IP 'strings'
+Single-quoted strings are evaluated as-is.  Their values are not
+expanded as with double-quoted strings above, and they are not
+interpreted as attribute references.
+.IP `strings`
+Back-quoted strings are evaluated by expanding the contents of the
+string, as described above for double-quoted strings.  The resulting
+command given inside of the string in a sub-shell, and taking the
+output as a string.  This behavior is much the same as that of Unix
+shells.
+
+Note that for security reasons, the input string is split into command
+and arguments before string expansion is done.
+
+For performance reasons, we suggest that the use of back-quoted
+strings be kept to a minimum.  Executing external programs is
+relatively expensive, and executing a large number of programs for
+every request can quickly use all of the CPU time in a server.  If you
+believe that you need to execute many programs, we suggest finding
+alternative ways to achieve the same result.  In some cases, using a
+real language may be sufficient.
+
+.IP /regex/im
+These strings are valid only on the right-hand side of a comparison,
+and then only when the comparison operator is "=~" or "!~".  They are
+regular expressions, as implemented by the local regular expression
+library on the system.  This is usually Posix regular expressions.
+
+The trailing 'i' is optional, and indicates that the regular
+expression match should be done in a case-insensitive fashion.
+
+The trailing 'm' is also optional, and indicates that carrot '^'
+and dollar '$' anchors should match on new lines as well as at the
+start and end of the subject string.
+
+If the comparison operator is "=~", then parentheses in the regular
+expression will define variables containing the matching text, as
+described below in the ATTRIBUTE REFERENCES section.
+.SH EXPANSIONS
+Attributes are expanded using the ATTRIBUTE REFERENCE syntax
+described above, and surrounding the reference with "%{...}"
+
+.DS
+	%{Attribute-Reference}
+.DE
+
+The result will be a string which contains the value of the attribute
+which was referenced, as a printable string.  If the attribute does
+not exist, the result will be an empty string.
+.PP
+Results of regular expression matches
+.RS
+If a regular expression match has previously been performed, then the
+special variable %{0} will contain a copy of the matched portion of
+the input string.  The variables %{1} through %{32} will contain the
+substring matches, starting from the left-most capture group, onwards.
+If there are more than 32 capture groups, the additional results will
+not be accessible.
+If the server is built with libpcre, the results of named capture groups
+are available using the "%{regex:capture group}" expansion.  They will
+also be accessible using the variables described above.
+Every time a regular expression is evaluated, whether it matches or not,
+the capture group values will be cleared.
+.RE
+.PP
+Obtaining results from databases
+.RS
+It is useful to query a database for some information, and to use the
+result in a condition.  The following syntax will call a module, pass
+it the given string, and replace the string expansion with the
+resulting string returned from the module.
+
+.DS
+	%{module: string ...}
+.DE
+
+The syntax of the string is module-specific.  Please read the module
+documentation for additional details.
+.RE
+.PP
+Conditional Syntax
+.RS
+Conditional syntax similar to that used in Unix shells may also be
+used.
+.IP %{%{Foo}:-bar}
+If %{Foo} has a value, returns that value.
+.br
+Otherwise, returns literal string "bar".
+.IP %{%{Foo}:-%{Bar}}
+If %{Foo} has a value, returns that value.
+.br
+Otherwise, returns the expansion of %{Bar}.
+
+These conditional expansions can be nested to almost any depth, such
+as with %{%{One}:-%{%{Two}:-%{Three}}}
+.RE
+.PP
+String lengths and arrays
+.RS
+Similar to a Unix shell, there are ways to reference string lengths,
+and the second or more instance of an attribute in a list.  If you
+need more than this functionality, we suggest using a real language.
+.IP %{strlen:string}
+The number of characters in "string".  If "string" does not exist,
+then the length also does not exist, instead of being zero.
+
+The "string" is expanded before the length is taken.
+
+.IP %{integer:Attribute-Name}
+The integer value of the Attribute-Name, instead of the enumerated
+name.
+
+e.g. If a request contains "Service-Type = Login-User", the expansion
+of %{integer:Service-Type} will yield "1".
+
+.IP %{hex:Attribute-Name}
+The hex value of the Attribute-Name, as a series of hex digits.
+
+e.g. If a request contains "Framed-IP-Address = 127.0.0.1", the expansion
+of %{hex:Framed-IP-Address} will yield "0x7f000001".
+
+.IP %{Attribute-Name[#]}
+The number of instances of Attribute-Name.
+
+e.g. If a request contains "User-Name = bob", the expansion
+of %{User-Name[#]} will yield "1".
+
+.IP %{Attribute-Name[*]}
+All values of Attribute-Name, concatenated together with ',' as the
+separator.
+
+.IP %{List-Name:[#]}
+The number of attributes in the named list.
+
+.IP %{List-Name:[*]}
+All values of attributes in the named-list, concatenated together with ','
+as the separator. Use the %{pairs:} xlat to get a list of attributes and
+values.
+
+e.g. If a response contains "Reply-Message = 'Hello', Reply-Message = 'bob'
+the expansion of "%{reply:Reply-Message[*]} will yield "Hello\\nbob"
+
+.SH ATTRIBUTE ASSIGNMENTS
+The attribute lists described above may be edited by listing one or
+more attributes in an "update" section.  Once the attributes have been
+defined, they may be referenced as described above in the ATTRIBUTE
+REFERENCES section.
+
+The following syntax defines attributes in an "update" section.  Each
+attribute and value has to be all on one line in the configuration
+file.  There is no need for commas or semi-colons after the value.
+
+.DS
+	Attribute-Reference = value
+.DE
+.PP
+Attribute Reference
+.RS
+The Attribute-Reference must be a reference (see above), using a name
+previously defined in a dictionary.  If an undefined name is used, the
+server will return an error, and will not start.
+
+.RE
+.IP Operators
+The operator used to assign the value of the attribute may be one of
+the following, with the given meaning.
+.RS
+.IP =
+Add the attribute to the list, if and only if an attribute of the same
+name is not already present in that list.
+.IP :=
+Add the attribute to the list.  If any attribute of the same name is
+already present in that list, its value is replaced with the value of
+the current attribute.
+.IP +=
+Add the attribute to the tail of the list, even if attributes of the
+same name are already present in the list. When the right hand side
+of the expression resolves to multiple values, it means add all values
+to the tail of the list.
+.IP ^=
+Add the attribute to the head of the list, even if attributes of the
+same name are already present in the list.  When the right hand side
+of the expression resolves to multiple values, it means prepend all
+values to the head of the list.
+.RE
+.PP
+Enforcement and Filtering Operators
+.RS
+The following operators may also be used in addition to the ones
+listed above.  Their function is to perform enforcement or filtering
+on attributes in a list.
+.IP -=
+Remove all matching attributes from the list.  Both the attribute name
+and value have to match in order for the attribute to be removed from
+the list.
+.IP ==
+Keep all matching attributes.  Both the attribute name and value have
+to match in order for the attribute to remain in the list.
+
+Note that this operator is very different than the '=' operator listed
+above!
+.IP !=
+Keep all attributes with matching name, and value not equal to the
+given one.
+.IP <
+Keep all attributes having values less than the value
+given here.  Any larger value is replaced by the value given here.  If
+no attribute exists, it is added with the value given here, as with
+"+=".
+.IP <=
+Keep all attributes having values less than, or equal to, the value
+given here.  Any larger value is replaced by the value given here.  If
+no attribute exists, it is added with the value given here, as with
+"+=".
+.IP >
+Keep all attributes having values greater than the value
+given here.  Any smaller value is replaced by the value given here.  If
+no attribute exists, it is added with the value given here, as with
+"+=".
+.IP >=
+Keep all attributes having values greater than, or equal to, the value
+given here.  Any smaller value is replaced by the value given here.  If
+no attribute exists, it is added with the value given here, as with
+"+=".
+.IP !*
+Delete all occurrences of the named attribute, no matter what the
+value.
+.IP =~
+Keep all attributes having values which match the given regular
+expression.  If no attribute matches, nothing else is done.
+.IP !~
+Keep all attributes having values which fail to match the given
+regular expression.  If no attribute matches, nothing else is done.
+.RE
+.IP Values
+.br
+The value can be an attribute reference, or an attribute-specific
+string.
+
+When the value is an attribute reference, it must take the form of
+"&Attribute-Name".  The leading "&" signifies that the value is a
+reference.  The "Attribute-Name" is an attribute name, such as
+"User-Name" or "request:User-Name".  When an attribute reference is
+used, both attributes must have the same data type.  For example,
+"User-Name := &NAS-Port" is invalid, because "User-Name" is a string,
+and "NAS-Port" is an integer.
+
+We recommend using the form "Attribute-1 = &Attribute-2" for updates,
+instead of "Attribute-1 = "%{Attribute-2}".  The first version will
+copy the attribute data, no matter what its form.  The second
+version will print the Attribute-2 to a string, and then parse it to
+create the value for Attribute-1.  This second version is slower
+and more fragile than the first one.
+
+When the value is an attribute-specific string, it can be a string,
+integer, IP address, etc.  The value may be expanded as described
+above in the DATA TYPES section, above.  For example, specifying
+"Framed-IP-Address = 127.0.0.1" will cause the "Framed-IP-Address"
+attribute to be set to the IP address "127.0.0.1".  However, using
+"Framed-IP-Address := \"%{echo: 127.0.0.1}\"" will cause the "echo"
+module to be run with a string "127.0.0.1".  The output of the "echo"
+module will then be parsed as an IP address, and placed into the
+Framed-IP-Address attribute.
+
+This flexibility means that you can assign an IP address by specifying
+it directly, or by having the address returned from a database query,
+or by having the address returned as the output of a program that is
+executed.
+
+When string values are finally assigned to an attribute, they can have a
+maximum length of 253 characters.  This limit is due in part to both
+protocol and internal server requirements.  That is, the strings in
+the language can be nearly 8k in length, say for a long SQL query.
+However, the output of that SQL query should be no more than 253
+characters in length.
+.SH OTHER KEYWORDS
+Other keywords in the language are taken from the names of modules
+loaded by the server.  These keywords are dependent on both the
+modules, and the local configuration.
+
+Some use keywords that are defined in the default configuration file
+are:
+.IP fail
+Cause the request to be treated as if a database failure had occurred.
+.IP noop
+Do nothing.  This also serves as an instruction to the configurable
+failover tracking that nothing was done in the current section.
+.IP ok
+Instructs the server that the request was processed properly.  This
+keyword can be used to over-ride earlier failures, if the local
+administrator determines that the failures are not catastrophic.
+.IP reject
+Causes the request to be immediately rejected
+.SH MODULE RETURN CODES
+When a module is called, it returns one of the following codes to
+"unlang", with the following meaning.
+
+.DS
+	notfound        information was not found
+.br
+	noop            the module did nothing
+.br
+	ok              the module succeeded
+.br
+	updated         the module updated the request
+.br
+	fail            the module failed
+.br
+	reject          the module rejected the request
+.br
+	userlock        the user was locked out
+.br
+	invalid         the configuration was invalid
+.br
+	handled         the module has handled the request itself
+.DE
+
+These return codes can be tested for in a condition, as described
+above in the CONDITIONS section.
+
+See also the file doc/configurable_failover for additional methods of
+trapping and modifying module return codes.
+.SH FILES
+/etc/raddb/radiusd.conf
+.SH "SEE ALSO"
+.BR radiusd.conf (5),
+.BR dictionary (5)
+.SH AUTHOR
+Alan DeKok <aland@deployingradius.com>
diff --git a/man/man5/users.5 b/man/man5/users.5
new file mode 100644
index 0000000..4586b96
--- /dev/null
+++ b/man/man5/users.5
@@ -0,0 +1,228 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH USERS 5 "04 Jan 2004" "" "FreeRADIUS user authorization file"
+.SH NAME
+users \- user authorization file for the FreeRADIUS server
+.SH DESCRIPTION
+The \fBusers\fP files reside in the files module configuration directory,
+by default \fB/etc/raddb/mods-config/files/\fP.  It contains a series
+of configuration directives which are used by the \fIfiles\fP 
+module to decide how to authorize and authenticate each user request.
+
+Every line starting with a hash sign
+.RB (' # ')
+is treated as comment and ignored.
+.PP
+Each entry of the file begins with a username, followed by a (possibly
+empty) list of check items, all on one line.  The next line begins
+with a tab, and a (possibly empty) list of reply items.  Each item in
+the check or reply item list is an attribute of the form \fBname =
+value\fP.  Multiple items may be placed on one line, in which case
+they must be separated by commas.  The reply items may be specified
+over multiple lines, in which case each line must end with a comma,
+and the last line of the reply items must not end with a comma.
+
+The check items are a list of attributes used to match the incoming
+request.  If the username matches, AND all of the check items match
+the incoming request, then the reply items are added to the list of
+attributes which will be used in the reply to that request.  This
+process is repeated for all of the entries in the users file.
+
+If the incoming request matches NO entry, then the request is
+rejected.
+
+.SH CAVEATS
+The special keyword \fBDEFAULT\fP matches any usernames.
+
+The entries are processed in order, from the top of the \fBusers\fP file,
+on down.  If an entry contains the special item \fBFall-Through =
+No\fP as a reply attribute, then the processing of the file stops, and
+no more entries are matched.  Any reply item list without any
+\fBFall-Through\fP attribute is treated as though it included a
+\fBFall-Through = No\fP attribute.
+
+If an entry contains the special item \fBFall-Through = Yes\fP as a
+reply attribute, then the processing proceeds to the next entry in
+order.
+
+Care should be taken when using \fBFall-Through\fP.  The server should
+be tested in debugging mode with a number of test requests, in order
+to verify that the configured entries behave as expected.
+
+The special attribute \fBAuth-Type\fP is used to identify the
+authentication type to be used for that user.  See the
+\fBdictionary\fP file for a list of permitted values for the
+\fBAuth-Type\fP attribute.
+
+Once the \fBusers\fP file has been processed, the request is authenticated,
+using the method given by \fBAuth-Type\fP.
+
+.SH OPERATORS
+Additional operators other than \fB=\fP may be used for the attributes in
+either the check item, or reply item list.  The following is a list of
+operators, and their meaning.
+
+.TP 0.5i
+.B "Attribute = Value"
+Not allowed as a check item for RADIUS protocol attributes.  It is
+allowed for server configuration attributes (Auth-Type, etc), and sets
+the value of on attribute, only if there is no other item of the
+same attribute.
+.br
+As a reply item, it means "add the item
+to the reply list, but only if there is no other item of the same
+attribute."
+
+.TP 0.5i
+.B "Attribute := Value"
+Always matches as a check item, and replaces in the configuration
+items any attribute of the same name.  If no attribute of that name
+appears in the request, then this attribute is added.
+.br
+As a reply item, it has an identical meaning, but for the reply items,
+instead of the request items.
+
+.TP 0.5i
+.B "Attribute == Value"
+As a check item, it matches if the named attribute is present in the
+request, AND has the given value.
+.br
+Not allowed as a reply item.
+
+.TP 0.5i
+.B "Attribute += Value"
+Always matches as a check item, and adds the current attribute with
+value to the tail of the list of configuration items.
+.br
+As a reply item, it has an identical meaning, but the attribute is
+added to the tail of the reply items list.
+
+.TP 0.5i
+.B "Attribute ^= Value"
+Always matches as a check item, and adds the current attribute with
+value to the head of the list of configuration items.
+.br
+As a reply item, it has an identical meaning, but the attribute is
+added to the head of the reply items list.
+
+.TP 0.5i
+.B "Attribute != Value"
+As a check item, matches if the given attribute is in the request, AND
+does not have the given value.
+.br
+Not allowed as a reply item.
+
+.TP 0.5i
+.B "Attribute > Value"
+As a check item, it matches if the request contains an attribute with
+a value greater than the one given.
+.br
+Not allowed as a reply item.
+
+.TP 0.5i
+.B "Attribute >= Value"
+As a check item, it matches if the request contains an attribute with
+a value greater than, or equal to the one given.
+.br
+Not allowed as a reply item.
+
+.TP 0.5i
+.B "Attribute < Value"
+As a check item, it matches if the request contains an attribute with
+a value less than the one given.
+.br
+Not allowed as a reply item.
+
+.TP 0.5i
+.B "Attribute <= Value"
+As a check item, it matches if the request contains an attribute with
+a value less than, or equal to the one given.
+.br
+Not allowed as a reply item.
+
+.TP 0.5i
+.B "Attribute =* Value"
+As a check item, it matches if the request contains the named
+attribute, no matter what the value is.
+.br
+Not allowed as a reply item.
+
+.TP 0.5i
+.B "Attribute !* Value"
+As a check item, it matches if the request does not contain the named
+attribute, no matter what the value is.
+.br
+Not allowed as a reply item.
+
+.SH EXAMPLES
+
+.DS
+bob	Cleartext-Password := "hello"
+
+.DE
+.RS
+Requests containing the User-Name attribute, with value "bob", will be
+authenticated using the "known good" password "hello".  There are no
+reply items, so the reply will be empty.
+.RE
+
+.DS
+DEFAULT Service-Type == Framed-User, Framed-Protocol == PPP
+.br
+	Service-Type = Framed-User,
+.br
+	Framed-Protocol = PPP,
+.br
+	Fall-Through = Yes
+
+.DE
+.RS
+If the request packet contains the attributes Service-Type and
+Framed-Protocol, with the given values, then include those attributes
+in the reply.
+
+That is, give the user what they ask for.  This entry also shows how
+to specify multiple reply items.
+.RE
+
+See the \fBusers\fP file supplied with the server for more examples
+and comments.
+
+.SH HINTS
+Run the server in debugging mode (\fB-X\fP), and use the
+\fBradclient\fP program to send it test packets which you think will
+match specific entries.  The server will print out which entries were
+matched for that request, so you can verify your expectations.  This
+should be the FIRST thing you do if you suspect problems with the
+file.
+
+Care should be taken when writing entries for the \fBusers\fP file.  It is
+easy to misconfigure the server so that requests are accepted when you
+wish to reject them.  The entries should be ordered, and the
+Fall-Through item should be used ONLY where it is required.
+
+Entries rejecting certain requests should go at the top of the file,
+and should not have a Fall-Through item in their reply items.  Entries
+for specific users, who do not have a Fall-Through item, should come
+next.  Any DEFAULT entries should usually come last, except as fall-through
+entries that set reply attributes.
+
+.SH FILES
+/etc/raddb/mods-config/files/
+.SH "SEE ALSO"
+.BR radclient (1),
+.BR radiusd (8),
+.BR dictionary (5),
+
+.SH AUTHOR
+The FreeRADIUS team.