[RADIATOR] "Expiration" attribute troubles

Hugh Irvine hugh at open.com.au
Wed Jul 9 00:02:27 CDT 2008


Hello Andrew -

The Radiator dictionary has Expiration defined as a "date" attribute,  
which is expected to be the number of seconds since Jan 1, 1970.

Hence the value that you are using is not being encoded properly when  
sent in the access accept.

See section 15.1.1 in the Radiator 4.2 reference manual ("doc/ref.pdf").

What format does your device expect to see as the value for the  
Expiration attribute?

regards

Hugh


On 9 Jul 2008, at 03:06, Andrew D. Clark wrote:

> On Tuesday 08 July 2008 02:18:14 am Hugh Irvine wrote:
>> Hello Andrew -
>>
>> Yes this is perfectly reasonable.
>>
>> I'll discuss the attribute collision with the developers.
>>
>> regards
>>
>> Hugh
>>
>
> So this works a bit better now, but not quite correctly.  Here's  
> the reply
> from the Radiator server fronting the Directory:
>
>> Tue Jul  8 11:37:14 2008: DEBUG: Radius::AuthLDAP2 looks for match  
>> with adc
>> [adc ]
>> Tue Jul  8 11:37:14 2008: DEBUG: ValidFrom date converted to:  
>> 1215363121
>> Tue Jul  8 11:37:14 2008: DEBUG: Expiration date converted to:  
>> 1215536041
>> Tue Jul  8 11:37:14 2008: DEBUG: Radius::AuthLDAP2 ACCEPT: : adc  
>> [adc]
>> Tue Jul  8 11:37:14 2008: DEBUG: AuthBy GROUP result: ACCEPT,
>> Tue Jul  8 11:37:14 2008: DEBUG: Access accepted for adc
>> Tue Jul  8 11:37:14 2008: DEBUG: Packet dump:
>> *** Sending to 134.84.20.25 port 60509 ....
>> Code:       Access-Accept
>> Identifier: 14
>> Authentic:  <144>J;N<194><198>v<15>o<218>H}<146><186><201><217>
>> Attributes:
>>         MS-CHAP2-Success =  
>> "<1>S=3636045083C8C43EC0C1AC62DBB664AE79776A0A"
>>         Expiration = 2008-07-08 11:54:01
>
> And what I see on my end with radpwtst:
>
> Tue Jul  8 11:37:14 2008: DEBUG: Packet dump:
> *** Received from 160.94.5.5 port 1645 ....
>
> Packet length = 77
> 02 0e 00 4d 2d a6 ce 82 e3 a1 f6 88 a4 5b 75 43
> 29 62 fd bc 1a 33 00 00 01 37 1a 2d 01 53 3d 33
> 36 33 36 30 34 35 30 38 33 43 38 43 34 33 45 43
> 30 43 31 41 43 36 32 44 42 42 36 36 34 41 45 37
> 39 37 37 36 41 30 41 15 06 00 00 00 00
> Code:       Access-Accept
> Identifier: 14
> Authentic:  -<166><206><130><227><161><246><136><164>[uC)b<253><188>
> Attributes:
>         MS-CHAP2-Success =  
> "<1>S=3636045083C8C43EC0C1AC62DBB664AE79776A0A"
>         Expiration = 0
>
> OK
>
> Both ends are running Radiator.  Is one of them misbehaving?
>
> -- 
> Andrew D. Clark
> Network Operations Engineer 	
> University of Minnesota, Networking/Telecom Services 	
> 2218 University Ave SE
> Minneapolis, MN 55414-3029
> Phone: 612-626-4880



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