6. Testing tools

Radiator download package multiple tools for testing:

6.1. radpwtst

radpwtst is a testing tool that sends requests to a RADIUS server, such as Radiator, and waits for a reply. Use it to send Access-Request, Accounting-Request (Stop and Start), and Status-Server requests. radpwtst checks that your Radiator server, or any other RADIUS server, is configured and behaving correctly, and also for checking if user's password is correct.
By default, radpwtst sends an Access-Request, waits up to 5 seconds for a reply, sends an Accounting-Request (Start), waits for a reply, then sends an Accounting-Request (Stop), and waits for a reply. You can change this behaviour with the command line flags.
Tip
When radpwtst is run with -interactive flag, it queries the password without local echo. This allows you to specify the password without the command line -password option.
Tip
If a Framed-IP-Address is received in an Access Accept, then radpwtst uses the address in subsequent Accounting Starts and Stops, unless the -framed_ip_address flag has been set. This allows simple testing of address allocation modules and such.
Tip
A fundamental requirement of the RADIUS protocol is that the RADIUS Client (in this case radpwtst) and the RADIUS Server (in this case Radiator) must use the same shared secret. If Radiator keeps rejecting your request with a “Bad Password” message, even though you are sure the password is correct, it may be because the shared secrets are not correct. Check the "Secret" line in your Radiator config file, and perhaps use the -secret command line argument to radpwtst. If you do not specify a -secret argument to radpwtst, it uses mysecret by default
The arguments to radpwtst are:
radpwtst  [-h] [-time] [-iterations n] [-iteration_delay f] [-timestamps]
          [-log_microseconds] [-trace [level]] [-notrace] [-onlyfailed] 
          [-print_stats] [-user username] [-password password]
          [-s server] [-secret secret] [-auth_port port] [-acct_port port]
          [-noauth] [-noacct] [-nostart] [-nostop] [-alive] [-status]
          [-chap] [-chap_nc] [-mschap] [-mschapv2] [-sip]
          [-eapmd5] [-eapotp] [-eapgtc] [-eapfastgtc] [-leap]
          [-motp_secret xxxxxxxxxxxxxxxx] [-eaphex xxxxxxxxxxxxx]
          [-interactive] [-code requestcode] [-accton] [-acctoff]
          [-identifier n] [-no_random] [-framed_ip_address address]
          [-state state] [-useoldascendpasswords] [-incrementuser]
          [-nas_ip_address address] [-nas_identifier string]
          [-nas_port port] [-nas_port_type type] [-service_type service]
          [-calling_station_id string] [-called_station_id string]
          [-session_id string] [-session_time n]
          [-delay_time n] [-input_octets n] [-output_octets n]
          [-timeout n] [-noreply] [-retries n] [-dictionary file,file]
          [-class string] [-message_authenticator]
          [-raw data] [-rawfile filename] [-rawfileseq filename]
          [-outport port] [-bind_address address]
          [-options optionfile] [-gui]
          [attribute=value]...

6.1.1. radpwtst option file

radpwtst options can be placed in an option file. The file format is one option per line. Leading and trailing white space is ignored. To preserve leading or trailing white space, use double quotes (") to surround the value. Empty lines and lines with # as first nonwhite space character are ignored. Use only one space between option name and value. See the example below.
# Set some defaults. Note: just one space between
# the option name and value
-trace 4
-nas_identifier " name with leading and trailing spaces "

# Attributes can have whitespace in the value only. Surround
# the value with " if there is trailing or leading space
Connect-Info=52100/31200 V91
radpwtst looks for options in /etc/radpwtstrc and $HOME/.radpwtstrc. It loads first the options file and then processes command line options. You can override options specified in the options file using command line options. For example, if the default trace level is 4 in the options file, you can temporarily use trace level 3 by using command line option -trace 3. This allows you to define the default parameters in the options file, but you can still temporarily use different values with command line parameters.

6.1.2. radpwtst examples

Send Access-Request and Accounting Start to server oscar.open.com.au for user mikem@your.realm and password jim. Authenticate with CHAP. Make sure the request includes Connect-Info of 52100/31200 V91:
radpwtst -s oscar.open.com.au -nostop -chap
      -user mikem@your.realm -password jim 
      Connect-Info="52100/31200 V91"
Send Server-Status request to fred.open.com.au, print the reply:
radpwtst -status -noauth -noacct -s fred.open.com.au 
      -trace -message_authenticator
Send 1000 Access-Requests to 1.2.3.4 for user fred, password jim, and print out how long it took:
radpwtst -iterations 1000 -noacct -user fred 
      -password jim -time
Send a Disconnect-Request:
radpwtst -noacct -noauth -code Disconnect-Request NAS-Port=1234
Make the GUI appear for extended interactive testing:
radpwtst -gui
Send an Access-Request to an IPv6 address:
radpwtst -noacct -s 2001:db8:100:f101::1
Send an Access-Request to the localhost loopback address using IPv6:
radpwtst -noacct -s ::1

6.1.3. radpwtst GUI

The radpwtst program will present a Graphical User Interface (GUI) when it is started with the -gui flag. If you select this option, the GUI will stay visible until dismissed. This allows you to send a number of different requests with a single mouse click, and to quickly and easily change the attributes to be sent. These features allow easy testing of Radiator (or any other RADIUS server for that matter), particularly when configuring a new realm or user.
Note
radpwtst -gui requires the Perl Tk module to be installed on your host machine.
The command line flags given to radpwtst are used to preconfigure the values you see in the interface. You can change the values at any time to affect the next request to be sent. Press the Start button to commence sending, and the Stop button to stop sending.
On each iteration, radpwtst will send one of each of the requests selected in the middle panel. The requests will contain attributes and values configured in the first panel, and the requests will be sent to the server and ports configured in the third panel. Not all attributes are sent in every request type: only the usual ones for that request type.
In the lower panel, you can trace the progress of each request and the reply, You can control the level of detail seen for each request and reply with the Options->Trace Level menu.

Figure 4. radpwtst Graphical User Interface

radpwtst.png

6.2. builddbm

builddbm is a testing tool that creates and updates DBM format user database files from flat file format user database files. For more information, see Section 9.3. DBM user database and Section 9.2. Flat file user database. It can also be used to print or delete the information for a single user from a DBM file.
DBM files should be used with Radiator if you require fast authentication, but also need to change your user database on the fly while Radiator is running, and you do not or cannot use <AuthBy SQL> or <AuthBy FILE> in Nocache mode.
Radiator will choose the best format of DBM file available to you, depending on which DBM modules are installed on your machine.
Tip
You can force it to choose a particular DBM file format by using the -t flag.
The arguments are:
builddbm [-z] [-u] [-f flatfile] [-d user] [-l user]
[-p]
[-t type] dbfile
  • -z
    This deletes all entries from the database before processing other commands.
  • -u
    This updates the mode and replaces user entries that already exist in the DBM file rather than showing an error.
  • -f flatfile
    The name of the flat file format user database to be used to populate the DBM file. The default value is dbfile, i.e. the name of the DBM file, without the .pag or .dir suffixes.
  • -d user
    This deletes the entry for user from the DBM file.
  • -l user
    This prints out the entry for user in a format that could be re-imported into builddbm.
  • -p
    This prints the contents of the DBM file in standard Livingston flat file format. The check and reply attributes of all users in the database are printed out in no particular order. The printed output goes to stdout.
  • -t dbmtype
    This forces builddbm to use a particular format of DBM file. The value of dbmtype can be AnyDBM_File, NDBM_File, DB_File, GDBM_File, SDBM_File or ODBM_File. Defaults to AnyDBM_File, which selects the best format on the host machine.
  • dbfile
    The base name of the DBM files to create or use. The actual filenames depend on the DBM module that Perl has selected, but, it is usually something like dbfile.dir and dbfile.pag. This is a mandatory parameter.

Example

Rebuild the entire DBM database in users.dir and users.pag from the users file, clearing old entries first:
builddbm -z users

Example

Update the Berkeley DB format database files all.db with the users in the file users:
builddbm -u -f users -t DB_File all.db

Example

Print the entry associated with the user mikem in the DBM files staff.dir, staff.pag:
builddbm -l mikem staff

6.3. buildsql

buildsql is a testing tool that creates or updates an SQL authentication table from the contents of a Unix password file or from a (Livingston) standard RADIUS users file. It can also be used to print or delete the information for a single user from an SQL authentication table.
Use an SQL database with Radiator if you require fast authentication, large user populations, and also need to change your user database on the fly while Radiator is running, and you do not or cannot use <AuthBy DBM> or <AuthBy FILE> in Nocache mode.
By default, buildsql connects to the SQL database specified by the -dbsource, -dbusername, and -dbauth command line flags. You must specify these flags. For more information about setting these flags for different database vendors, see Section 19. Using SQL with various database vendors.
By default, buildsql inserts or updates records in a table called SUBSCRIBERS, but you can change this with a command line flag. By default, it only affects four columns in the table: USERNAME, PASSWORD, CHECKATTR, REPLYATTR, but you can change this with command line arguments. All other columns are unaffected by buildsql, so you can have arbitrarily complicated tables. You can change the names of the columns that buildsql uses with command line arguments. The default names are compatible with the default names used by the SQL authentication module.
The arguments are:
buildsql [-z] [-u] [-f] [-d user] [-l user] [-v]
-dbsource dbi:drivername:option
[-dbusername dbusername] [-dbauth auth]
[-password | -dbm | -flat]
[-tablename name]
[-username_column columnname]
[-password_column columnname]
[encryptedpassword]
[-checkattr_column columnname]
[-replyattr_column columnname] file ....
  • -z
    This deletes all user entries from the database before processing other commands.
  • -u
    This is the update mode. It replaces user entries that already exist in the database rather than shows error about constraint violations.
  • -f
    This forces database update for non-defined fields.
  • -d user
    This deletes user from the SQL database
  • -l user
    This prints out the entry for user in a format that could be re-imported into buildsql.
  • -v
    This prints out every SQL statement being issued before its executed
  • -dbsource dbi:drivername:option
    This specifies the data source name of the database to connect to. Must be specified.
  • -dbusername username
    This specifies the user name to use to connect to the SQL database.
  • dbauth password
    This specifies the password for dbusername. Not required for some database types.
  • -password
    The source files are in Unix password file format. For more information, see Section 9.4. Unix password file.
  • -dbm
    The source files are in DB file format. For more information, see Section 9.3. DBM user database.
  • -t dbmtype
    Forces buildsql to use a particular format of DBM file. The value of dbmtype can be AnyDBM_File, NDBM_File, DB_File, GDBM_File, SDBM_File, or ODBM_File. The default value is AnyDBM_File, which selects the best format on the host machine.
  • -flat
    The source files are in standard RADIUS flat file format. For more information, see Section 9.2. Flat file user database. This is the default. If no input file type is specified, -flat is assumed.
  • -tablename name
    This specifies the name of the database table to use. The default value is SUBSCRIBERS.
  • -username_column columnname
    This specifies the name of the column where the user name are stored. The default value is USERNAME.
  • -password_column columnname
    This specifies the name of the column where the passwords are stored. The default value is PASSWORD.
  • -checkattr_column columnname
    This specifies the name of the column where the Check Items are stored. The default value is CHECKATTR.
  • -replyattr_column columnname
    This specifies the name of the column where the Reply Items are stored. The default value is REPLYATTR.
  • -encryptedpassword
    This handles and prints all passwords as if they were encrypted. When printing passwords with -l, the password is given with Encrypted-Password.
If neither -password or -dbm is specified, the input files are assumed to be in flat file format. For more information, see Section 9.2. Flat file user database.

Example

Rebuild the entire SQL database from the /etc/passwd file, clearing the old entries first. Then connect to an Oracle database SID called osc as user system and password manager. Use the default table and column names:
buildsql -z -dbsource dbi:Oracle:osc \
      -dbusername system -dbauth manager \
      -password /etc/passwd

Example

Print out the attributes for user mikem in the same database:
buildsql dbsource dbi:Oracle:osc \
      -dbusername system -dbauth manager -l mikem

Example

Delete user mikem from the same database:
buildsql dbsource dbi:Oracle:osc \
      -dbusername system -dbauth manager -d mikem