and found comment that the coding is referring to RFC 2138. The
dictionary in the Radius server is following the RFC 2865.
Could this be
Posted via http://www.ruby-forum.com/.
This is how dictionaries work:
A RADIUS packet is made up of a header and a payload. The header has the
[ Code - 1 Octet ][ Identifier - 1 Octet ][ Length - 2 Octets ][
Authenticator - 16 Octets ]
Where the code is one of 1 - Access-Request, 2 - Access-Accept, 3 -
Access-Reject, 4 - Accounting-Request, 5 - Accounting-Reponse, 11
Access-Challenge and distinguishes the type of RADIUS packet.
The Identifier is used to perform threading and link initial requests
The Length is the sum of all fields in the packet (much be between 20
4096 octets. According to spec, longer messages get trimmed at 4096,
ones are thrown away.
The Authenticator region is used differently depending on whether the
is a request or a responose and contains either completely random data,
calculated using MD5 hashes on the value of the code, identifier, length
request-authenticator random payload, followed by packet payload and
The header is followed by the payload, where each attribute and value
transmitted as such:
[ Number - 1 Octet ][ Length - > 3 ][ Value - dependent on attribute
The Number is between 1 and 255 and is what gets translated by the
dictionary. For example, Attribute-Number 39 is translated to
“Framed-AppleTalk-Zone” in the standard dictionaries, so that you can
to it as such instead of using the number.
The Length is the length of the attribute-value pair, and must be larger
than 3 (1 octet for the Number, 1 octet for the Length, 1 octet for the
The Value is dependent on the attribute name in that the dictionary also
specifies the type of value. An abbribute number is mapped to one of:
Integer (INT) (4 Octets, 32-bit unsigned)
Enumerated (ENUM) (4 Octets, 32-bit unsigned)
IP Address (IPADDR) (4 Octets, 32 bit)
Character String (STRING) (1-253 Octets, variable)
Date (DATE) (4 Octets, 32-bit unsigned)
Binary (BINARY) (1 bit)
So a dictionary entry such as
1 User-Name STRING
Signifies that Attribute Number 1 can be referred to as ‘User-Name’ and
carries as a value a string between 1 and 253 octets in length.
Since that means there can only be 255 higher order RADIUS attributes,
is also the special case of vvendor-specific attributes (VSAs). They
the Attribute-Number 26 and a payload consisting of:
[ ID - 4 octets ][ Number - 1 Octet ][ Length > 7 ][ Value - dependent
attribute number ]
Which essentially behaves much like an attribute/value pair wrapped in
attribute/value pair, adding a field for the Vendor ID. The vendor ID is
coded using NMPECs in network byte ordering and is unique to the vendor,
again described by an entry in a dictionary.
So therefore, client and server strictly speaking do not need to
identical dictionaries, in that they can be free to change values in the
second column of format (“Attribute-Number”, “Human-Readable String”,
Kind”) so that the client can refer to Attribute-Number 1 as ‘User-Name’
while the server refers to it as ‘Username’. They do, however, usually
to have dictionary entries to be able to refer to the fields in some
your server is sending packets with AV-pairs that your client does not
dictionaries for, you’d have to go to a very low level to interpret them
byte level instead of being able to use the Ruby interface, which deals
the pairs once they’re translated from the dictionary.
Hope that helps,