billmax documentation   BillMax Billing Solutions
  877.245.5629
  sales@billmax.com
 
DICTIONARY
Prev  Chapter 5. RADIUS related information  Next

Name

dictionary — dictionary translations for parsing RADIUS requests

Synopsis Notes

../raddb/dictionary

DESCRIPTION

The dictionary file resides in the Interlink AAA Server configuration directory (named .../raddb somewhere). It contains a list of dictionary translations which the Interlink AAA Server will use to parse incoming requests and to generate outgoing responses. Comments are indicated by leading pound sign ('#') characters. All such comment lines are ignored (as are blank lines).

All transactions are composed of Attribute/Value Pairs. The value of each attribute is specified as one of several data <type>s.

Valid <type>s include:

string
octets - -253 undistinguished octets (experimental, for display only)
vendor - first octet is zero, then three octets IANA #, then the rest
tag-int - single octet followed by three octets of integer value
tag-str - single octet followed by -252 octets
abinary - -254 Ascend binary filter octets
ipaddr - octets in network byte order
integer - bit integer value in big endian order (high byte first)
octet - bit integer value
short - bit integer value in big endian order (high byte first)
date - bit value in big endian order - seconds since :00:00 GMT, Jan. , 1970

The ATTRIBUTE entries consist of four required fields and one optional fifth field: ATTRIBUTE <attribute-name> <integer-encoding> <type> [<pruning>]

The VALUE entries consist of four fields: VALUE <attribute-name> <value-name> <integer-encoding>

For example:

ATTRIBUTE Framed-Protocol integer (1,0)

and

VALUE Framed-Protocol PPP

The optional <pruning> field on attribute lines controls the following features of the Interlink AAA Server:

  • whether the attribute is ever sent to the NAS

  • how the NAS reacts to a reply which contains the attribute

  • other features such as logging and encapsulation

The syntax of the <pruning> expressions is as follows: [ ( [<ack>] [ [ [,] [<nak>] ] [ [,] [ MAY | MUST | CONFIG | NOLOG | [NO] ENCAPS ] ] ] ) ]


    \\\\__first feature above__/      \\\\__other features above__/  

In the first feature above, <ack> and <nak> are one of '0', '1' or '*'. The <ack> and <nak> values affect Access-Accept and Access-Reject replies, respectively. These values represent:

no attributes of this kind are part of the final reply (DEFAULT)

at most, one attribute of this kind may be part of the final reply

"*"

any number of attributes of this kind may be part of the final reply

The default values for both <ack> and <nak> are zero! Keep this in mind when adding vendor specific attributes since they will not be returned to the NAS in any replies unless this expression exists.

The remaining keywords define how the NAS reacts to the attribute and how the Interlink AAA Server deals with certain attributes:

"MUST"

the NAS must reject the request if it does not recognize this attribute

MAY

the NAS may ignore the attribute if not recognized (DEFAULT)

CONFIG

the attribute is a configuration item

NOLOG

the attribute is not allowed to be logged

ENCAPS

the attribute is always encapsulated within the Vendor-Specific attribute (26) regardless of the vendor (DEFAULT)

NOENCAPS

the attribute is not encapsulated within the Vendor-Specific attribute (26)

The CONFIG keyword is only for the internal use of this Interlink AAA Server and must be given by itself (i.e., (config) at the end of the attribute line).

If any value is omitted, but the comma is present for that value, then just that value takes on the default. The keywords MAY and MUST only are meaningful for RADIUS Version Two (DIAMETER).

A new syntax for handling vendor specific attributes is supported: <vendor>:<attribute-string>

where <vendor> is the vendor's name and <attribute-string> is a unique string (for that vendor). This syntax may be used here and in the users file. There is an alternate syntax available for specifying vendor specific attributes and values. Vendor specific attribute and value identifier strings may be defined in the vendors file which may be used in place of the default strings ATTRIBUTE and VALUE.

The dictionary file is read by radiusd at startup and whenever a HUP signal is received by radiusd. The Interlink AAA Server detects any out-of-date configuration files upon receipt of a Status-Server (or Management-Poll) request and re-reads all the configuration files. This file is maintained by the system administrator using a text editor.

FILES

../raddb/dictionary

SEE ALSO

signal(3), users(5), vendors(5), radiusd(8), radcheck(8), radpwtst(8)

Prev  Up  Next
billmax.realms  Home  CLIENTS
Document Revision A for BillMax 2.2.0   -   Copyright © 1997-2006 The iSpark Group, Inc.

All rights reserved. No part of this documentation may be reproduced or transmitted in any fashion without written permission by The iSpark Group, Inc. This documentation is for the sole use of licensees of the BillMax billing software created by The iSpark Group, Inc. Making the documentation available to a non-licensee of BillMax without written permission of The iSpark Group, Inc. is a violation of the use of this documentation.

While precautions have been taken in the preparation of this documentation, The iSpark Group, Inc. assumes neither liability nor responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

All terms mentioned that are known to be trademarks have been appropriately capitalized. Use of the a trademark does not affect the validity of any trademark or service mark.

Links to third-party Web sites are provided for convenience. The iSpark Group, Inc. is not responsible for any content contained in the third-party Web sites.

Comments about this documentation may be sent to doc@billmax.com