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