Attribute References

The attribute reference can also be qualified with a list reference. When no list is given, the server looks in the input packet list for the named attribute.

When an attribute appears multiple times in a list, this syntax allows you to address the attributes as if they were array entries. The <index> value defines which attribute to address. The [0] value refers to the first attributes, [1] refers to the second attribute, etc.

The <index> can be an integer (0..1000).

The indexes are limited to 1000, because there are essentially no protocols which have more than 1000 attributes.

The <index> can also be a special value n, which means "the last attribute in the list.

The <index> can also be a reference to a numerical attribute.

The reference must be to an attribute of numerical data type. Structural data types and string or octets types are not allowed. If the index is out of bounds (e.g. negative), then the reference fails.

The main utility of attribute indexes is in a foreach loop.

The <index> can also be an expression which is calculated at run time. The expression must not cause the server to call an external database, script, etc. The main purpose of these expressions is to calculated an index without first placing it into another attribute.

If the index must be calculated from an external database call or script, simply place that value into an attribute first, and then use that attribute as in index.

The expression must be in an expansion block: %{…​}.

In some cases, attributes are nested or grouped. The child reference syntax is used to address a particular child attribute. Multiple levels of parent / child nesting can be performed by simply appending the name of another child attribute, separated by the . character.

All of the above syntaxes can be used interchangeably, at any nesting level. The examples are presented

When the server decodes data from the network, that data can sometimes be malformed. When this happens, the server creates a "raw" attribute, usually of the octets data type. This process allows all data received be the server to be processed, and used in policies. It also allows the server to receive and forward attributes which are unknown to the server.

It is possible to create "raw" attributes in policies, simply by prefixing the name with the word raw.. For example, the Framed-IP-Address attribute is normally an IPv4 address (type ipv4addr) which is four octets long. However, it is possible to create a Framed-IP-Address which is only one octet long, via the following assignment:

The raw. prefix must be listed first, before any list reference is given.

It is also possible to create raw attributes from numbers. For example, Vendor-Specific.Cisco.AVPAir is 25.9.1:

While the server accepts these strings, it is generally a bad idea to use them. Instead, you should add a local dictionary definition for the attribute.

FreeRADIUS version 3 used the & character for attribute references. However, the & character was sometimes not allowed, such as in the users file. In other cases such as conditions, it was allowed by not required. This behavior made the configuration more confusing.

Version 4 fixes that by dropping the & entirely. It is allowed for backwards compatibility, but if used it is ignored. All of the documentation and configuration files have been updated to remove the & character. A future version of the server will be updated to remove that backwards compatibility, and at some future time, using & will result in an error.