slash13 wrote:

okay let me explain a little bit more, I want to set up a scenario where for example a printing service gets accounted. i need to add custom attributes e.g. Printing-Service-Name or Printing-Color or Printing-Pages etc. to freeradius. in which specific dictionary do i need to add these attributes?

raddb/dictionary.

and how do i have to adjust the radacct table?

See the documentation for the SQL server you use.

freeradius daemon and db is deployed on ubuntu 10 and the client is a normal personal computer sending RADIUS packets to the server. my goal is to start an accounting session, send my custom attributes to the server, store it in the db and then stop the accounting session.

If you're not sure about dictionaries && SQL, creating your own custom attributes is not really a good idea. Use the existin attributes, there are lots of them. Alan DeKok.

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): http://www.ietf.org/assignments/radius-types/radius-types.xml#radius-types-1 ...or apply for an IANA enterprise number then define your own radius vendor-specific attributes: http://pen.iana.org/pen/PenApplication.page 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: /etc/raddb/dictionary: # 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 /etc/raddb/sites-enabled/...: authorize { # decode the key=value attributes if (My-Printing-Info =~ /service-name=(.+)/) { update request { Printing-Service-Name = "${1}" } } # repeat for each key=value type sql } ...then you can do this: cat >test.pkt <<EOF Acct-Status-Type=Start Acct-Session-Id=xxx My-Printing-Info=service-name=foo My-Printing-Info=color=yes EOF cat test.pkt | radclient $host acct $secret

slash13 wrote:

thanks mr mayers, i think you explained that very well since i am neither an expert on linux or c++ =)

The dictionaries are documented in raddb/dictionary, and "man dictionary". This includes explicit comments that attribute 3000 can't go into a packet.

actually my goal was to compare the accounting feature of RADIUS(freeradius) to a protocol called LIFPEAR (Lightweight and Flexible Protocol to Exchange Accounting Records) which I have developed for my bachelor thesis at the CSG lab from University of Zürich. Well I also got into the same kind of problems with freeDiameter...

I have a hard time seeing what's more lightweight than RADIUS. Alan DeKok.