Hi,<br><br>i install freeradius for my hotspot.<br>when i test radius on server i can't get :<br>rad_recv: Access-Accept packet from host 127.0.0.1<br><br>radiusd.conf<br><br>#######################################################<br>
# -*- text -*-<br>##<br>## radiusd.conf    -- FreeRADIUS server configuration file.<br>##<br>##    <a href="http://www.freeradius.org/">http://www.freeradius.org/</a><br>##    $Id$<br>##<br><br>######################################################################<br>
#<br>#    Read "man radiusd" before editing this file.  See the section<br>#    titled DEBUGGING.  It outlines a method where you can quickly<br>#    obtain the configuration you want, without running into<br>#    trouble.<br>
#<br>#    Run the server in debugging mode, and READ the output.<br>#<br>#        $ radiusd -X<br>#<br>#    We cannot emphasize this point strongly enough.  The vast<br>#    majority of problems can be solved by carefully reading the<br>
#    debugging output, which includes warnings about common issues,<br>#    and suggestions for how they may be fixed.<br>#<br>#    There may be a lot of output, but look carefully for words like:<br>#    "warning", "error", "reject", or "failure".  The messages there<br>
#    will usually be enough to guide you to a solution.<br>#<br>#    If you are going to ask a question on the mailing list, then<br>#    explain what you are trying to do, and include the output from<br>#    debugging mode (radiusd -X).  Failure to do so means that all<br>
#    of the responses to your question will be people telling you<br>#    to "post the output of radiusd -X".<br><br>######################################################################<br>#<br>#      The location of other config files and logfiles are declared<br>
#      in this file.<br>#<br>#      Also general configuration for modules can be done in this<br>#      file, it is exported through the API to modules that ask for<br>#      it.<br>#<br>#    See "man radiusd.conf" for documentation on the format of this<br>
#    file.  Note that the individual configuration items are NOT<br>#    documented in that "man" page.  They are only documented here,<br>#    in the comments.<br>#<br>#    As of 2.0.0, FreeRADIUS supports a simple processing language<br>
#    in the "authorize", "authenticate", "accounting", etc. sections.<br>#    See "man unlang" for details.<br>#<br><br>prefix = /usr<br>exec_prefix = /usr<br>sysconfdir = /etc<br>localstatedir = /var<br>
sbindir = ${exec_prefix}/sbin<br>logdir = /var/log/freeradius<br>raddbdir = /etc/freeradius<br>radacctdir = ${logdir}/radacct<br><br>#<br>#  name of the running server.  See also the "-n" command-line option.<br>
name = freeradius<br><br>#  Location of config and logfiles.<br>confdir = ${raddbdir}<br>run_dir = ${localstatedir}/run/${name}<br><br># Should likely be ${localstatedir}/lib/radiusd<br>db_dir = ${raddbdir}<br><br>#<br># libdir: Where to find the rlm_* modules.<br>
#<br>#   This should be automatically set at configuration time.<br>#<br>#   If the server builds and installs, but fails at execution time<br>#   with an 'undefined symbol' error, then you can use the libdir<br>#   directive to work around the problem.<br>
#<br>#   The cause is usually that a library has been installed on your<br>#   system in a place where the dynamic linker CANNOT find it.  When<br>#   executing as root (or another user), your personal environment MAY<br>
#   be set up to allow the dynamic linker to find the library.  When<br>#   executing as a daemon, FreeRADIUS MAY NOT have the same<br>#   personalized configuration.<br>#<br>#   To work around the problem, find out which library contains that symbol,<br>
#   and add the directory containing that library to the end of 'libdir',<br>#   with a colon separating the directory names.  NO spaces are allowed.<br>#<br>#   e.g. libdir = /usr/local/lib:/opt/package/lib<br>#<br>
#   You can also try setting the LD_LIBRARY_PATH environment variable<br>#   in a script which starts the server.<br>#<br>#   If that does not work, then you can re-configure and re-build the<br>#   server to NOT use shared libraries, via:<br>
#<br>#    ./configure --disable-shared<br>#    make<br>#    make install<br>#<br>libdir = /usr/lib/freeradius<br><br>#  pidfile: Where to place the PID of the RADIUS server.<br>#<br>#  The server may be signalled while it's running by using this<br>
#  file.<br>#<br>#  This file is written when ONLY running in daemon mode.<br>#<br>#  e.g.:  kill -HUP `cat /var/run/radiusd/radiusd.pid`<br>#<br>pidfile = ${run_dir}/${name}.pid<br><br>#  chroot: directory where the server does "chroot".<br>
#<br>#  The chroot is done very early in the process of starting the server.<br>#  After the chroot has been performed it switches to the "user" listed<br>#  below (which MUST be specified).  If "group" is specified, it switchs<br>
#  to that group, too.  Any other groups listed for the specified "user"<br>#  in "/etc/group" are also added as part of this process.<br>#<br>#  The current working directory (chdir / cd) is left *outside* of the<br>
#  chroot until all of the modules have been initialized.  This allows<br>#  the "raddb" directory to be left outside of the chroot.  Once the<br>#  modules have been initialized, it does a "chdir" to ${logdir}.  This<br>
#  means that it should be impossible to break out of the chroot.<br>#<br>#  If you are worried about security issues related to this use of chdir,<br>#  then simply ensure that the "raddb" directory is inside of the chroot,<br>
#  end be sure to do "cd raddb" BEFORE starting the server.<br>#<br>#  If the server is statically linked, then the only files that have<br>#  to exist in the chroot are ${run_dir} and ${logdir}.  If you do the<br>
#  "cd raddb" as discussed above, then the "raddb" directory has to be<br>#  inside of the chroot directory, too.<br>#<br>#chroot = /path/to/chroot/directory<br><br># user/group: The name (or #number) of the user/group to run radiusd as.<br>
#<br>#   If these are commented out, the server will run as the user/group<br>#   that started it.  In order to change to a different user/group, you<br>#   MUST be root ( or have root privleges ) to start the server.<br>
#<br>#   We STRONGLY recommend that you run the server with as few permissions<br>#   as possible.  That is, if you're not using shadow passwords, the<br>#   user and group items below should be set to radius'.<br>
#<br>#  NOTE that some kernels refuse to setgid(group) when the value of<br>#  (unsigned)group is above 60000; don't use group nobody on these systems!<br>#<br>#  On systems with shadow passwords, you might have to set 'group = shadow'<br>
#  for the server to be able to read the shadow password file.  If you can<br>#  authenticate users while in debug mode, but not in daemon mode, it may be<br>#  that the debugging mode server is running as a user that can read the<br>
#  shadow info, and the user listed below can not.<br>#<br>#  The server will also try to use "initgroups" to read /etc/groups.<br>#  It will join all groups where "user" is a member.  This can allow<br>
#  for some finer-grained access controls.<br>#<br>user = freerad<br>group = freerad<br><br>#  max_request_time: The maximum time (in seconds) to handle a request.<br>#<br>#  Requests which take more time than this to process may be killed, and<br>
#  a REJECT message is returned.<br>#<br>#  WARNING: If you notice that requests take a long time to be handled,<br>#  then this MAY INDICATE a bug in the server, in one of the modules<br>#  used to handle a request, OR in your local configuration.<br>
#<br>#  This problem is most often seen when using an SQL database.  If it takes<br>#  more than a second or two to receive an answer from the SQL database,<br>#  then it probably means that you haven't indexed the database.  See your<br>
#  SQL server documentation for more information.<br>#<br>#  Useful range of values: 5 to 120<br>#<br>max_request_time = 30<br><br>#  cleanup_delay: The time to wait (in seconds) before cleaning up<br>#  a reply which was sent to the NAS.<br>
#<br>#  The RADIUS request is normally cached internally for a short period<br>#  of time, after the reply is sent to the NAS.  The reply packet may be<br>#  lost in the network, and the NAS will not see it.  The NAS will then<br>
#  re-send the request, and the server will respond quickly with the<br>#  cached reply.<br>#<br>#  If this value is set too low, then duplicate requests from the NAS<br>#  MAY NOT be detected, and will instead be handled as seperate requests.<br>
#<br>#  If this value is set too high, then the server will cache too many<br>#  requests, and some new requests may get blocked.  (See 'max_requests'.)<br>#<br>#  Useful range of values: 2 to 10<br>#<br>cleanup_delay = 5<br>
<br>#  max_requests: The maximum number of requests which the server keeps<br>#  track of.  This should be 256 multiplied by the number of clients.<br>#  e.g. With 4 clients, this number should be 1024.<br>#<br>#  If this number is too low, then when the server becomes busy,<br>
#  it will not respond to any new requests, until the 'cleanup_delay'<br>#  time has passed, and it has removed the old requests.<br>#<br>#  If this number is set too high, then the server will use a bit more<br>#  memory for no real benefit.<br>
#<br>#  If you aren't sure what it should be set to, it's better to set it<br>#  too high than too low.  Setting it to 1000 per client is probably<br>#  the highest it should be.<br>#<br>#  Useful range of values: 256 to infinity<br>
#<br>max_requests = 1024<br><br>#  listen: Make the server listen on a particular IP address, and send<br>#  replies out from that address. This directive is most useful for<br>#  hosts with multiple IP addresses on one interface.<br>
#<br>#  If you want the server to listen on additional addresses, or on<br>#  additionnal ports, you can use multiple "listen" sections.<br>#<br>#  Each section make the server listen for only one type of packet,<br>
#  therefore authentication and accounting have to be configured in<br>#  different sections.<br>#<br>#  The server ignore all "listen" section if you are using '-i' and '-p'<br>#  on the command line.<br>
#<br>listen {<br>    #  Type of packets to listen for.<br>    #  Allowed values are:<br>    #    auth    listen for authentication packets<br>    #    acct    listen for accounting packets<br>    #    proxy   IP to use for sending proxied packets<br>
    #    detail  Read from the detail file.  For examples, see<br>    #               raddb/sites-available/copy-acct-to-home-server<br>    #    status  listen for Status-Server packets.  For examples,<br>    #        see raddb/sites-available/status<br>
    #    coa     listen for CoA-Request and Disconnect-Request<br>    #        packets.  For examples, see the file<br>    #        raddb/sites-available/coa-server<br>    #<br>    type = auth<br><br>    #  Note: "type = proxy" lets you control the source IP used for<br>
    #        proxying packets, with some limitations:<br>    #<br>    #    * A proxy listener CANNOT be used in a virtual server section.<br>    #    * You should probably set "port = 0".<br>    #    * Any "clients" configuration will be ignored.<br>
    #<br>    #  See also proxy.conf, and the "src_ipaddr" configuration entry<br>    #  in the sample "home_server" section.  When you specify the<br>    #  source IP address for packets sent to a home server, the<br>
    #  proxy listeners are automatically created.<br><br>    #  IP address on which to listen.<br>    #  Allowed values are:<br>    #    dotted quad (1.2.3.4)<br>    #       hostname    (<a href="http://radius.example.com">radius.example.com</a>)<br>
    #       wildcard    (*)<br>    ipaddr = 127.0.0.1<br><br>    #  OR, you can use an IPv6 address, but not both<br>    #  at the same time.<br>#    ipv6addr = ::    # any.  ::1 == localhost<br><br>    #  Port on which to listen.<br>
    #  Allowed values are:<br>    #    integer port number (1812)<br>    #    0 means "use /etc/services for the proper port"<br>    port = 0<br><br>    #  Some systems support binding to an interface, in addition<br>
    #  to the IP address.  This feature isn't strictly necessary,<br>    #  but for sites with many IP addresses on one interface,<br>    #  it's useful to say "listen on all addresses for eth0".<br>    #<br>
    #  If your system does not support this feature, you will<br>    #  get an error if you try to use it.<br>    #<br>#    interface = eth0<br><br>    #  Per-socket lists of clients.  This is a very useful feature.<br>    #<br>
    #  The name here is a reference to a section elsewhere in<br>    #  radiusd.conf, or clients.conf.  Having the name as<br>    #  a reference allows multiple sockets to use the same<br>    #  set of clients.<br>    #<br>
    #  If this configuration is used, then the global list of clients<br>    #  is IGNORED for this "listen" section.  Take care configuring<br>    #  this feature, to ensure you don't accidentally disable a<br>
    #  client you need.<br>    #<br>    #  See clients.conf for the configuration of "per_socket_clients".<br>    #<br>#    clients = per_socket_clients<br>}<br><br>#  This second "listen" section is for listening on the accounting<br>
#  port, too.<br>#<br>listen {<br>    ipaddr = 127.0.0.1<br>#    ipv6addr = ::<br>    port = 0<br>    type = acct<br>#    interface = eth0<br>#    clients = per_socket_clients<br>}<br><br>#  hostname_lookups: Log the names of clients or just their IP addresses<br>
#  e.g., <a href="http://www.freeradius.org">www.freeradius.org</a> (on) or 206.47.27.232 (off).<br>#<br>#  The default is 'off' because it would be overall better for the net<br>#  if people had to knowingly turn this feature on, since enabling it<br>
#  means that each client request will result in AT LEAST one lookup<br>#  request to the nameserver.   Enabling hostname_lookups will also<br>#  mean that your server may stop randomly for 30 seconds from time<br>#  to time, if the DNS requests take too long.<br>
#<br>#  Turning hostname lookups off also means that the server won't block<br>#  for 30 seconds, if it sees an IP address which has no name associated<br>#  with it.<br>#<br>#  allowed values: {no, yes}<br>#<br>hostname_lookups = no<br>
<br>#  Core dumps are a bad thing.  This should only be set to 'yes'<br>#  if you're debugging a problem with the server.<br>#<br>#  allowed values: {no, yes}<br>#<br>allow_core_dumps = no<br><br>#  Regular expressions<br>
#<br>#  These items are set at configure time.  If they're set to "yes",<br>#  then setting them to "no" turns off regular expression support.<br>#<br>#  If they're set to "no" at configure time, then setting them to "yes"<br>
#  WILL NOT WORK.  It will give you an error.<br>#<br>regular_expressions    = yes<br>extended_expressions    = yes<br><br>#<br>#  Logging section.  The various "log_*" configuration items<br>#  will eventually be moved here.<br>
#<br>log {<br>    #<br>    #  Destination for log messages.  This can be one of:<br>    #<br>    #    files - log to "file", as defined below.<br>    #    syslog - to syslog (see also the "syslog_facility", below.<br>
    #    stdout - standard output<br>    #    stderr - standard error.<br>    #<br>    #  The command-line option "-X" over-rides this option, and forces<br>    #  logging to go to stdout.<br>    #<br>    destination = files<br>
<br>    #<br>    #  The logging messages for the server are appended to the<br>    #  tail of this file if destination == "files"<br>    #<br>    #  If the server is running in debugging mode, this file is<br>    #  NOT used.<br>
    #<br>    file = ${logdir}/radius.log<br><br>    #<br>    #  If this configuration parameter is set, then log messages for<br>    #  a *request* go to this file, rather than to radius.log.<br>    #<br>    #  i.e. This is a log file per request, once the server has accepted<br>
    #  the request as being from a valid client.  Messages that are<br>    #  not associated with a request still go to radius.log.<br>    #<br>    #  Not all log messages in the server core have been updated to use<br>    #  this new internal API.  As a result, some messages will still<br>
    #  go to radius.log.  Please submit patches to fix this behavior.<br>    #<br>    #  The file name is expanded dynamically.  You should ONLY user<br>    #  server-side attributes for the filename (e.g. things you control).<br>
    #  Using this feature MAY also slow down the server substantially,<br>    #  especially if you do thinks like SQL calls as part of the<br>    #  expansion of the filename.<br>    #<br>    #  The name of the log file should use attributes that don't change<br>
    #  over the lifetime of a request, such as User-Name,<br>    #  Virtual-Server or Packet-Src-IP-Address.  Otherwise, the log<br>    #  messages will be distributed over multiple files.<br>    #<br>    #  Logging can be enabled for an individual request by a special<br>
    #  dynamic expansion macro:  %{debug: 1}, where the debug level<br>    #  for this request is set to '1' (or 2, 3, etc.).  e.g.<br>    #<br>    #    ...<br>    #    update control {<br>    #           Tmp-String-0 = "%{debug:1}"<br>
    #    }<br>    #    ...<br>    #<br>    #  The attribute that the value is assigned to is unimportant,<br>    #  and should be a "throw-away" attribute with no side effects.<br>    #<br>    #requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log<br>
<br>    #<br>    #  Which syslog facility to use, if ${destination} == "syslog"<br>    #<br>    #  The exact values permitted here are OS-dependent.  You probably<br>    #  don't want to change this.<br>    #<br>
    syslog_facility = daemon<br><br>    #  Log the full User-Name attribute, as it was found in the request.<br>    #<br>    # allowed values: {no, yes}<br>    #<br>    stripped_names = no<br><br>    #  Log authentication requests to the log file.<br>
    #<br>    #  allowed values: {no, yes}<br>    #<br>    auth = no<br><br>    #  Log passwords with the authentication requests.<br>    #  auth_badpass  - logs password if it's rejected<br>    #  auth_goodpass - logs password if it's correct<br>
    #<br>    #  allowed values: {no, yes}<br>    #<br>    auth_badpass = no<br>    auth_goodpass = no<br><br>    #  Log additional text at the end of the "Login OK" messages.<br>    #  for these to work, the "auth" and "auth_goopass" or "auth_badpass"<br>
    #  configurations above have to be set to "yes".<br>    #<br>    #  The strings below are dynamically expanded, which means that<br>    #  you can put anything you want in them.  However, note that<br>    #  this expansion can be slow, and can negatively impact server<br>
    #  performance.<br>    #<br>#    msg_goodpass = ""<br>#    msg_badpass = ""<br>}<br><br>#  The program to execute to do concurrency checks.<br>checkrad = ${sbindir}/checkrad<br><br># SECURITY CONFIGURATION<br>
#<br>#  There may be multiple methods of attacking on the server.  This<br>#  section holds the configuration items which minimize the impact<br>#  of those attacks<br>#<br>security {<br>    #<br>    #  max_attributes: The maximum number of attributes<br>
    #  permitted in a RADIUS packet.  Packets which have MORE<br>    #  than this number of attributes in them will be dropped.<br>    #<br>    #  If this number is set too low, then no RADIUS packets<br>    #  will be accepted.<br>
    #<br>    #  If this number is set too high, then an attacker may be<br>    #  able to send a small number of packets which will cause<br>    #  the server to use all available memory on the machine.<br>    #<br>    #  Setting this number to 0 means "allow any number of attributes"<br>
    max_attributes = 200<br><br>    #<br>    #  reject_delay: When sending an Access-Reject, it can be<br>    #  delayed for a few seconds.  This may help slow down a DoS<br>    #  attack.  It also helps to slow down people trying to brute-force<br>
    #  crack a users password.<br>    #<br>    #  Setting this number to 0 means "send rejects immediately"<br>    #<br>    #  If this number is set higher than 'cleanup_delay', then the<br>    #  rejects will be sent at 'cleanup_delay' time, when the request<br>
    #  is deleted from the internal cache of requests.<br>    #<br>    #  Useful ranges: 1 to 5<br>    reject_delay = 1<br><br>    #<br>    #  status_server: Whether or not the server will respond<br>    #  to Status-Server requests.<br>
    #<br>    #  When sent a Status-Server message, the server responds with<br>    #  an Access-Accept or Accounting-Response packet.<br>    #<br>    #  This is mainly useful for administrators who want to "ping"<br>
    #  the server, without adding test users, or creating fake<br>    #  accounting packets.<br>    #<br>    #  It's also useful when a NAS marks a RADIUS server "dead".<br>    #  The NAS can periodically "ping" the server with a Status-Server<br>
    #  packet.  If the server responds, it must be alive, and the<br>    #  NAS can start using it for real requests.<br>    #<br>    #  See also raddb/sites-available/status<br>    #<br>    status_server = yes<br>}<br><br>
# PROXY CONFIGURATION<br>#<br>#  proxy_requests: Turns proxying of RADIUS requests on or off.<br>#<br>#  The server has proxying turned on by default.  If your system is NOT<br>#  set up to proxy requests to another server, then you can turn proxying<br>
#  off here.  This will save a small amount of resources on the server.<br>#<br>#  If you have proxying turned off, and your configuration files say<br>#  to proxy a request, then an error message will be logged.<br>#<br>
#  To disable proxying, change the "yes" to "no", and comment the<br>#  $INCLUDE line.<br>#<br>#  allowed values: {no, yes}<br>#<br>proxy_requests  = yes<br>$INCLUDE proxy.conf<br><br><br># CLIENTS CONFIGURATION<br>
#<br>#  Client configuration is defined in "clients.conf".  <br>#<br><br>#  The 'clients.conf' file contains all of the information from the old<br>#  'clients' and 'naslist' configuration files.  We recommend that you<br>
#  do NOT use 'client's or 'naslist', although they are still<br>#  supported.<br>#<br>#  Anything listed in 'clients.conf' will take precedence over the<br>#  information from the old-style configuration files.<br>
#<br>$INCLUDE clients.conf<br><br><br># THREAD POOL CONFIGURATION<br>#<br>#  The thread pool is a long-lived group of threads which<br>#  take turns (round-robin) handling any incoming requests.<br>#<br>#  You probably want to have a few spare threads around,<br>
#  so that high-load situations can be handled immediately.  If you<br>#  don't have any spare threads, then the request handling will<br>#  be delayed while a new thread is created, and added to the pool.<br>#<br>#  You probably don't want too many spare threads around,<br>
#  otherwise they'll be sitting there taking up resources, and<br>#  not doing anything productive.<br>#<br>#  The numbers given below should be adequate for most situations.<br>#<br>thread pool {<br>    #  Number of servers to start initially --- should be a reasonable<br>
    #  ballpark figure.<br>    start_servers = 5<br><br>    #  Limit on the total number of servers running.<br>    #<br>    #  If this limit is ever reached, clients will be LOCKED OUT, so it<br>    #  should NOT BE SET TOO LOW.  It is intended mainly as a brake to<br>
    #  keep a runaway server from taking the system with it as it spirals<br>    #  down...<br>    #<br>    #  You may find that the server is regularly reaching the<br>    #  'max_servers' number of threads, and that increasing<br>
    #  'max_servers' doesn't seem to make much difference.<br>    #<br>    #  If this is the case, then the problem is MOST LIKELY that<br>    #  your back-end databases are taking too long to respond, and<br>
    #  are preventing the server from responding in a timely manner.<br>    #<br>    #  The solution is NOT do keep increasing the 'max_servers'<br>    #  value, but instead to fix the underlying cause of the<br>    #  problem: slow database, or 'hostname_lookups=yes'.<br>
    #<br>    #  For more information, see 'max_request_time', above.<br>    #<br>    max_servers = 32<br><br>    #  Server-pool size regulation.  Rather than making you guess<br>    #  how many servers you need, FreeRADIUS dynamically adapts to<br>
    #  the load it sees, that is, it tries to maintain enough<br>    #  servers to handle the current load, plus a few spare<br>    #  servers to handle transient load spikes.<br>    #<br>    #  It does this by periodically checking how many servers are<br>
    #  waiting for a request.  If there are fewer than<br>    #  min_spare_servers, it creates a new spare.  If there are<br>    #  more than max_spare_servers, some of the spares die off.<br>    #  The default values are probably OK for most sites.<br>
    #<br>    min_spare_servers = 3<br>    max_spare_servers = 10<br><br>    #  There may be memory leaks or resource allocation problems with<br>    #  the server.  If so, set this value to 300 or so, so that the<br>    #  resources will be cleaned up periodically.<br>
    #<br>    #  This should only be necessary if there are serious bugs in the<br>    #  server which have not yet been fixed.<br>    #<br>    #  '0' is a special value meaning 'infinity', or 'the servers never<br>
    #  exit'<br>    max_requests_per_server = 0<br>}<br><br># MODULE CONFIGURATION<br>#<br>#  The names and configuration of each module is located in this section.<br>#<br>#  After the modules are defined here, they may be referred to by name,<br>
#  in other sections of this configuration file.<br>#<br>modules {<br>    #<br>    #  Each module has a configuration as follows:<br>    #<br>    #    name [ instance ] {<br>    #        config_item = value<br>    #        ...<br>
    #    }<br>    #<br>    #  The 'name' is used to load the 'rlm_name' library<br>    #  which implements the functionality of the module.<br>    #<br>    #  The 'instance' is optional.  To have two different instances<br>
    #  of a module, it first must be referred to by 'name'.<br>    #  The different copies of the module are then created by<br>    #  inventing two 'instance' names, e.g. 'instance1' and 'instance2'<br>
    #<br>    #  The instance names can then be used in later configuration<br>    #  INSTEAD of the original 'name'.  See the 'radutmp' configuration<br>    #  for an example.<br>    #<br><br>    #<br>    #  As of 2.0.5, most of the module configurations are in a<br>
    #  sub-directory.  Files matching the regex /[a-zA-Z0-9_.]+/<br>    #  are loaded.  The modules are initialized ONLY if they are<br>    #  referenced in a processing section, such as authorize,<br>    #  authenticate, accounting, pre/post-proxy, etc.<br>
    #<br>    $INCLUDE ${confdir}/modules/<br><br>    #  Extensible Authentication Protocol<br>    #<br>    #  For all EAP related authentications.<br>    #  Now in another file, because it is very large.<br>    #<br>    $INCLUDE eap.conf<br>
<br>    #  Include another file that has the SQL-related configuration.<br>    #  This is another file only because it tends to be big.<br>    #<br>#    $INCLUDE sql.conf<br><br>    #<br>    #  This module is an SQL enabled version of the counter module.<br>
    #<br>    #  Rather than maintaining seperate (GDBM) databases of<br>    #  accounting info for each counter, this module uses the data<br>    #  stored in the raddacct table by the sql modules. This<br>    #  module NEVER does any database INSERTs or UPDATEs.  It is<br>
    #  totally dependent on the SQL module to process Accounting<br>    #  packets.<br>    #<br>#    $INCLUDE sql/mysql/counter.conf<br><br>    #<br>    #  IP addresses managed in an SQL table.<br>    #<br>#    $INCLUDE sqlippool.conf<br>
}<br><br># Instantiation<br>#<br>#  This section orders the loading of the modules.  Modules<br>#  listed here will get loaded BEFORE the later sections like<br>#  authorize, authenticate, etc. get examined.<br>#<br>#  This section is not strictly needed.  When a section like<br>
#  authorize refers to a module, it's automatically loaded and<br>#  initialized.  However, some modules may not be listed in any<br>#  of the following sections, so they can be listed here.<br>#<br>#  Also, listing modules here ensures that you have control over<br>
#  the order in which they are initalized.  If one module needs<br>#  something defined by another module, you can list them in order<br>#  here, and ensure that the configuration will be OK.<br>#<br>instantiate {<br>    #<br>
    #  Allows the execution of external scripts.<br>    #  The entire command line (and output) must fit into 253 bytes.<br>    #<br>    #  e.g. Framed-Pool = `%{exec:/bin/echo foo}`<br>    exec<br><br>    #<br>    #  The expression module doesn't do authorization,<br>
    #  authentication, or accounting.  It only does dynamic<br>    #  translation, of the form:<br>    #<br>    #    Session-Timeout = `%{expr:2 + 3}`<br>    #<br>    #  So the module needs to be instantiated, but CANNOT be<br>
    #  listed in any other section.  See 'doc/rlm_expr' for<br>    #  more information.<br>    #<br>    expr<br><br>    #<br>    # We add the counter module here so that it registers<br>    # the check-name attribute before any module which sets<br>
    # it<br>#    daily<br>    expiration<br>    logintime<br><br>    # subsections here can be thought of as "virtual" modules.<br>    #<br>    # e.g. If you have two redundant SQL servers, and you want to<br>    # use them in the authorize and accounting sections, you could<br>
    # place a "redundant" block in each section, containing the<br>    # exact same text.  Or, you could uncomment the following<br>    # lines, and list "redundant_sql" in the authorize and<br>    # accounting sections.<br>
    #<br>    #redundant redundant_sql {<br>    #    sql1<br>    #    sql2<br>    #}<br>}<br><br>######################################################################<br>#<br>#    Policies that can be applied in multiple places are listed<br>
#    globally.  That way, they can be defined once, and referred<br>#    to multiple times.<br>#<br>######################################################################<br>$INCLUDE policy.conf<br><br>######################################################################<br>
#<br>#    Load virtual servers.<br>#<br>#    This next $INCLUDE line loads files in the directory that<br>#    match the regular expression: /[a-zA-Z0-9_.]+/<br>#<br>#    It allows you to define new virtual servers simply by placing<br>
#    a file into the raddb/sites-enabled/ directory.<br>#<br>$INCLUDE sites-enabled/<br><br>######################################################################<br>#<br>#    All of the other configuration sections like "authorize {}",<br>
#    "authenticate {}", "accounting {}", have been moved to the<br>#    the file:<br>#<br>#        raddb/sites-available/default<br>#<br>#    This is the "default" virtual server that has the same<br>
#    configuration as in version 1.0.x and 1.1.x.  The default<br>#    installation enables this virtual server.  You should<br>#    edit it to create policies for your local site.<br>#<br>#    For more documentation on virtual servers, see:<br>
#<br>#        raddb/sites-available/README<br>#<br>######################################################################<br><br>and client.conf<br><br>#################################################################"<br>
<br>#<br>#    Please read the documentation file ../doc/processing_users_file,<br>#    or 'man 5 users' (after installing the server) for more information.<br>#<br>#    This file contains authentication security and configuration<br>
#    information for each user.  Accounting requests are NOT processed<br>#    through this file.  Instead, see 'acct_users', in this directory.<br>#<br>#    The first field is the user's name and can be up to<br>
#    253 characters in length.  This is followed (on the same line) with<br>#    the list of authentication requirements for that user.  This can<br>#    include password, comm server name, comm server port number, protocol<br>
#    type (perhaps set by the "hints" file), and huntgroup name (set by<br>#    the "huntgroups" file).<br>#<br>#    If you are not sure why a particular reply is being sent by the<br>#    server, then run the server in debugging mode (radiusd -X), and<br>
#    you will see which entries in this file are matched.<br>#<br>#    When an authentication request is received from the comm server,<br>#    these values are tested. Only the first match is used unless the<br>#    "Fall-Through" variable is set to "Yes".<br>
#<br>#    A special user named "DEFAULT" matches on all usernames.<br>#    You can have several DEFAULT entries. All entries are processed<br>#    in the order they appear in this file. The first entry that<br>#    matches the login-request will stop processing unless you use<br>
#    the Fall-Through variable.<br>#<br>#    If you use the database support to turn this file into a .db or .dbm<br>#    file, the DEFAULT entries _have_ to be at the end of this file and<br>#    you can't have multiple entries for one username.<br>
#<br>#    Indented (with the tab character) lines following the first<br>#    line indicate the configuration values to be passed back to<br>#    the comm server to allow the initiation of a user session.<br>#    This can include things like the PPP configuration values<br>
#    or the host to log the user onto.<br>#<br>#    You can include another `users' file with `$INCLUDE users.other'<br>#<br><br>#<br>#    For a list of RADIUS attributes, and links to their definitions,<br>#    see:<br>
#<br>#    <a href="http://www.freeradius.org/rfc/attributes.html">http://www.freeradius.org/rfc/attributes.html</a><br>#<br>testing Cleartext-Password := "password"<br><br>#<br># Deny access for a specific user.  Note that this entry MUST<br>
# be before any other 'Auth-Type' attribute which results in the user<br># being authenticated.<br>#<br># Note that there is NO 'Fall-Through' attribute, so the user will not<br># be given any additional resources.<br>
#<br>#lameuser    Auth-Type := Reject<br>#        Reply-Message = "Your account has been disabled."<br><br>#<br># Deny access for a group of users.<br>#<br># Note that there is NO 'Fall-Through' attribute, so the user will not<br>
# be given any additional resources.<br>#<br>#DEFAULT    Group == "disabled", Auth-Type := Reject<br>#        Reply-Message = "Your account has been disabled."<br>#<br><br>#<br># This is a complete entry for "steve". Note that there is no Fall-Through<br>
# entry so that no DEFAULT entry will be used, and the user will NOT<br># get any attributes in addition to the ones listed here.<br>#<br>#steve    Cleartext-Password := "testing"<br>#    Service-Type = Framed-User,<br>
#    Framed-Protocol = PPP,<br>#    Framed-IP-Address = 172.16.3.33,<br>#    Framed-IP-Netmask = 255.255.255.0,<br>#    Framed-Routing = Broadcast-Listen,<br>#    Framed-Filter-Id = "std.ppp",<br>#    Framed-MTU = 1500,<br>
#    Framed-Compression = Van-Jacobsen-TCP-IP<br><br>#<br># This is an entry for a user with a space in their name.<br># Note the double quotes surrounding the name.<br>#<br>#"John Doe"    Cleartext-Password := "hello"<br>
#        Reply-Message = "Hello, %{User-Name}"<br><br>#<br># Dial user back and telnet to the default host for that port<br>#<br>#Deg    Cleartext-Password := "ge55ged"<br>#    Service-Type = Callback-Login-User,<br>
#    Login-IP-Host = 0.0.0.0,<br>#    Callback-Number = "9,5551212",<br>#    Login-Service = Telnet,<br>#    Login-TCP-Port = Telnet<br><br>#<br># Another complete entry. After the user "dialbk" has logged in, the<br>
# connection will be broken and the user will be dialed back after which<br># he will get a connection to the host "timeshare1".<br>#<br>#dialbk    Cleartext-Password := "callme"<br>#    Service-Type = Callback-Login-User,<br>
#    Login-IP-Host = timeshare1,<br>#    Login-Service = PortMaster,<br>#    Callback-Number = "9,1-800-555-1212"<br><br>#<br># user "swilson" will only get a static IP number if he logs in with<br># a framed protocol on a terminal server in Alphen (see the huntgroups file).<br>
#<br># Note that by setting "Fall-Through", other attributes will be added from<br># the following DEFAULT entries<br>#<br>#swilson    Service-Type == Framed-User, Huntgroup-Name == "alphen"<br>#        Framed-IP-Address = 192.168.1.65,<br>
#        Fall-Through = Yes<br><br>#<br># If the user logs in as 'username.shell', then authenticate them<br># using the default method, give them shell access, and stop processing<br># the rest of the file.<br>#<br>
#DEFAULT    Suffix == ".shell"<br>#        Service-Type = Login-User,<br>#        Login-Service = Telnet,<br>#        Login-IP-Host = your.shell.machine<br><br><br>#<br># The rest of this file contains the several DEFAULT entries.<br>
# DEFAULT entries match with all login names.<br># Note that DEFAULT entries can also Fall-Through (see first entry).<br># A name-value pair from a DEFAULT entry will _NEVER_ override<br># an already existing name-value pair.<br>
#<br><br>#<br># Set up different IP address pools for the terminal servers.<br># Note that the "+" behind the IP address means that this is the "base"<br># IP address. The Port-Id (S0, S1 etc) will be added to it.<br>
#<br>#DEFAULT    Service-Type == Framed-User, Huntgroup-Name == "alphen"<br>#        Framed-IP-Address = 192.168.1.32+,<br>#        Fall-Through = Yes<br><br>#DEFAULT    Service-Type == Framed-User, Huntgroup-Name == "delft"<br>
#        Framed-IP-Address = 192.168.2.32+,<br>#        Fall-Through = Yes<br><br>#<br># Sample defaults for all framed connections.<br>#<br>#DEFAULT    Service-Type == Framed-User<br>#    Framed-IP-Address = 255.255.255.254,<br>
#    Framed-MTU = 576,<br>#    Service-Type = Framed-User,<br>#    Fall-Through = Yes<br><br>#<br># Default for PPP: dynamic IP address, PPP mode, VJ-compression.<br># NOTE: we do not use Hint = "PPP", since PPP might also be auto-detected<br>
#    by the terminal server in which case there may not be a "P" suffix.<br>#    The terminal server sends "Framed-Protocol = PPP" for auto PPP.<br>#<br>DEFAULT    Framed-Protocol == PPP<br>    Framed-Protocol = PPP,<br>
    Framed-Compression = Van-Jacobson-TCP-IP<br><br>#<br># Default for CSLIP: dynamic IP address, SLIP mode, VJ-compression.<br>#<br>DEFAULT    Hint == "CSLIP"<br>    Framed-Protocol = SLIP,<br>    Framed-Compression = Van-Jacobson-TCP-IP<br>
<br>#<br># Default for SLIP: dynamic IP address, SLIP mode.<br>#<br>DEFAULT    Hint == "SLIP"<br>    Framed-Protocol = SLIP<br><br>#<br># Last default: rlogin to our main server.<br>#<br>#DEFAULT<br>#    Service-Type = Login-User,<br>
#    Login-Service = Rlogin,<br>#    Login-IP-Host = <a href="http://shellbox.ispdomain.com">shellbox.ispdomain.com</a><br><br># #<br># # Last default: shell on the local terminal server.<br># #<br># DEFAULT<br>#     Service-Type = Administrative-User<br>
<br># On no match, the user is denied access.<br><br>toto1 Auth-Type := Local, User-Password == "toto"<br>tata1 Auth-Type := Local, User-Password == "tata"<br>########################################################################<br>