[RADIATOR] "Expiration" attribute troubles

Andrew D. Clark adc at umn.edu
Tue Jul 8 00:29:47 CDT 2008


On Monday 07 July 2008 06:19:52 pm Hugh Irvine wrote:
> Hello Andrew -
>
> I suggest you alter the second definition in the dictionary as
> follows (you'll need to restart Radiator to re-read the dictionary):
>
>
> ATTRIBUTE       OSC-Expiration              90480001        string
>
>
> and see how you go with Expiration then.
>
> This appears to be a historical artifact, as "Expiration" was not
> initially defined in the RFC's.
>
> Can you tell me what you are using this for?

Sure.  I've got a device - a Trapeze wireless controller to be exact - which 
supports start and end times on accounts (VSAs which I've listed as 
Trapeze-Start-Date and Trapeze-End-Date in my dictionary).  I've also got a 
campus directory (run by a different group) which supports start and end 
times on accounts and with which I communicate via a RADIUS frontend.  I'd 
like the directory folks to hand back the expiration time for an account if 
it has one (they just return a reject if the account login is outside the 
allowed window).  They could return the vendor specific attribute for this 
specific use, but that wouldn't be very portable for various devices that 
might support account windows.  So they hand me back the standard expiration 
attribute and then I in turn translate that into what is needed to support 
this particular implementation.

Seem reasonable?

Andrew Clark

>
> regards
>
> Hugh
>
> On 8 Jul 2008, at 07:45, Andrew D. Clark wrote:
> > I'm trying to use the expiration attribute in a reply message, but
> > it gets
> > discarded.
> >
> > It's being pulled from LDAP and mapped like so
> >
> > AuthAttrDef umnValidUntil, Expiration, reply
> >
> > Apparently it's not a valid radius attribute.
> >
> > Mon Jul  7 15:25:58 2008: WARNING: Invalid reply item Expiration
> > ignored
> >
> > I noticed there are two definitions of "Expiration" in the
> > dictionary, a
> > standard one, and a Radiator internal one:
> >
> > ATTRIBUTE       Expiration                      21      date
> > ATTRIBUTE       Expiration              90480001        string
> >
> > Is the internal definition squashing the standard Expiration
> > attribute?  Is
> > such a collision of attribute names wise?  Is there a way around this?
> >
> > --
> > Andrew D. Clark
> > Network Operations Engineer
> > University of Minnesota, Networking/Telecom Services
> > 2218 University Ave SE
> > Minneapolis, MN 55414-3029
> > Phone: 612-626-4880
> >
> > _______________________________________________
> > radiator mailing list
> > radiator at open.com.au
> > http://www.open.com.au/mailman/listinfo/radiator
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/archives/
> radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> Have you checked the RadiusExpert wiki:
> http://www.open.com.au/wiki/index.php/Main_Page




More information about the radiator mailing list