freeradius 2.1.10 & postgresql & custom attributes

Phil Mayers p.mayers at
Fri Jan 21 13:37:40 CET 2011

On 21/01/11 11:58, slash13 wrote:
> Okay so I disabled the sql feature completely, actually I only need sort of a
> proof-of-concept to measure some packets.

As Alan says, this is a pretty expert use of RADIUS. You're essentially 
defining a new use of the protocol, and lots of big companies get this 
wrong. My advice would be to think hard - is this really the route you 
want to take? Wouldn't a well-tested printing protocol be a better choice?

> my /etc/freeradius/dictionary contains now these two custom attributes:
> ATTRIBUTE       Printing-Service-Name   3001    string
> ATTRIBUTE       Printing-Color               3002    string

Attribute numbers >255 are internal only; they cannot be sent on the 
wire (because the radius attribute number in packets is a 1-byte field).

You could try to find existing (probably vendor-specific) attributes and 
re-use those.

You could use the "reserved for private use" radius attributes (192-240):

...or apply for an IANA enterprise number then define your own radius 
vendor-specific attributes:

In all cases, you should consider radius attribute a scarce resource. 
You might therefore want to define a single attribute and use key=value 
format for the contents, for example:


# real on-the-wire attribute
ATTRIBUTE My-Printing-Info 192 string
# we will decode into this
ATTRIBUTE Printing-Service-Name 3001 string
ATTRIBUTE Printing-Color        3002 string


authorize {
   # decode the key=value attributes

   if (My-Printing-Info =~ /service-name=(.+)/) {
     update request {
       Printing-Service-Name = "${1}"
   # repeat for each key=value type


...then you can do this:

cat >test.pkt <<EOF

cat test.pkt | radclient $host acct $secret

More information about the Freeradius-Users mailing list