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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
