(RADIATOR) diameter to radius access request conversion creates undefined Authenticator field

Blake Ulmer bulmer at TataraSystems.com
Tue Mar 20 12:36:47 CST 2007


Hello,
 
My environment is using Radiator 3.16 (tried using both rpm and patched
UNIX install) on RHEL4 for diameter to radius conversion.  I've tried
googling around, searching through the archives, looking through docs,
and haven't been able to find any information about the problem I'm
having.  Forgive me if this is something simple that I'm missing.
 
I'm using diapwtst (simply, "perl diapwtst -user <user> -password
<password>") to send a diameter access request to Radiator, have
Radiator convert it to a radius request, and send it off to a third
party radius server for acceptance/rejection.  The problem is, once the
diameter conversion takes place, the resulting radius access request
contains an undefined 'Authentic' (authenticator) field, and so the
radius server rejects it (bad password).
 
My radiusd config file is the default "diameter-server.cfg" file that
comes with this 3.16, with a few changes.  First, I commented out all
TLS related things.  Secondly, I added an entry to allow a specific
realm to proxy my request to my radius server:
 
<Realm hal9002.com>
    <AuthBy RADIUS>
        Host hal9002
        AuthPort 1812
        AcctPort 1813
        Secret <secret>
        StripFromRequest Timestamp,GRIC-Timestamp
    </AuthBy>
</Realm>
 
I will also post below this a snippet of the TRACE logs according to
radiusd for the request.
 
Proxying basic radius requests works fine using radpwtst to create the
requests, when running radiusd with a radius only config file, and the
above Realm entry.  I even copied $p->setauthenticator() from radpwtst
into an appropriate place in ServerDIAMETER.pm to give the converted
request a hard-coded authenticator and the access request is accepted
using diapwtst.
 
So, my round and about question is, is there a reason the authenticator
is not being set (UNDEF) when the diameter request is converted?  Is
there a setting in the diameter-server.cfg file I'm missing?
 
I'm fairly sure that the Authenticator field is required in the radius
rfc, as it is used for hashing the password, so I don't think the radius
server I'm using is being too strict on accepting the request.
 
If anyone can point out what I'm missing, or what the deal is, that
would be great.
 
Thank you,
Blake Ulmer
 
 
************************************************************************
********
Tue Mar 20 13:35:26 2007: DEBUG: zulu.open.com.au <- testoriginhost
recv_v1msg:
  Code:           265 (AA)
  Version:        1
  Flags:          0x80 (R)
  Application ID: 1 (Nasreq)
  Hop-to-Hop ID:  1
  End-to-End ID:  3050307585
  Attributes:
    Session-Id: 64, testoriginhost;1234;1,
    Auth-Application-Id: 64, 1,
    Origin-Host: 64, testoriginhost,
    Origin-Realm: 64, testoriginrealm,
    Destination-Realm: 64, testdestrealm,
    Auth-Request-Type: 64, AUTHORIZE_AUTHENTICATE,
    User-Name: 64, bob at hal9002.com,
    User-Password: 64, <pw>,
    Called-Station-Id: 64, 123456789,
    Calling-Station-Id: 64, 987654321,
    NAS-Port: 64, 1234,
Tue Mar 20 13:35:26 2007: DEBUG: StateMachine::event R-Rcv-Message in
state R-Open. Calling Process
Tue Mar 20 13:35:26 2007: DEBUG: zulu.open.com.au Process
Tue Mar 20 13:35:26 2007: DEBUG: Packet dump:
*** Diameter request converted to Radius request ....
Code:       Access-Request
Identifier: UNDEF
Authentic:  UNDEF
Attributes:
        NAS-Identifier = "testoriginhost"
        User-Name = "bob at hal9002.com"
        User-Password = <pw>
        Called-Station-Id = "123456789"
        Calling-Station-Id = "987654321"
        NAS-Port = 1234
 
Tue Mar 20 13:35:26 2007: DEBUG: Handling request with Handler
'Realm=hal9002.com'
Tue Mar 20 13:35:26 2007: DEBUG:  Deleting session for bob at hal9002.com,
127.0.0.1, 1234
Tue Mar 20 13:35:26 2007: DEBUG: Handling with Radius::AuthRADIUS
Tue Mar 20 13:35:26 2007: DEBUG: AuthBy RADIUS creates new local socket
'0.0.0.0' for sending requests
Tue Mar 20 13:35:26 2007: DEBUG: Packet dump:
*** Sending to 192.168.3.248 port 1812 ....
 
Packet length = 99
01 01 00 63 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 20 10 74 65 73 74 6f 72 69 67 69 6e
68 6f 73 74 01 11 62 6f 62 40 68 61 6c 39 30 30
32 2e 63 6f 6d 02 12 64 ad 7b 80 ce f7 78 f3 a8
a3 f8 3b 4b 7e 46 49 1e 0b 31 32 33 34 35 36 37
38 39 1f 0b 39 38 37 36 35 34 33 32 31 05 06 00
00 04 d2
Code:       Access-Request
Identifier: 1
Authentic:  UNDEF
Attributes:
        NAS-Identifier = "testoriginhost"
        User-Name = "bob at hal9002.com"
        User-Password = <encrypted pw>
        Called-Station-Id = "123456789"
        Calling-Station-Id = "987654321"
        NAS-Port = 1234
************************************************************************
********
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20070320/b2f0f4e9/attachment.html>


More information about the radiator mailing list