[RADIATOR] "Expiration" attribute troubles

Hugh Irvine hugh at open.com.au
Tue Jul 8 02:18:14 CDT 2008


Hello Andrew -

Yes this is perfectly reasonable.

I'll discuss the attribute collision with the developers.

regards

Hugh


On 8 Jul 2008, at 15:29, Andrew D. Clark wrote:

> 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
>



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

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.




More information about the radiator mailing list