(RADIATOR) accounting request Acct-Session-Id lost in conversion from diameter to radius
Mike McCauley
mikem at open.com.au
Wed Mar 21 15:58:24 CST 2007
Hello Blake,
thanks for your note.
Like radpwtst, diapwtst is intended to be able to add arbitrary attributes to
the requests it sends, however a problem prevented that from working
correctly in diapwtst. That problem has now been fixed in the latest patch
set. We apologise for that.
So now you should be able to do this sort of thing:
diapwtst blah blah blah Accounting-Session-Id=12345
You should note that diapwtst is intended only to be a testing tool and not
used as part of a production environment.
Hope that helps.
Cheers.
On Thursday 22 March 2007 02:01, Blake Ulmer wrote:
> Thank you both for your replies. I was not aware that DIAMETER had
> multiple session id attributes, but the explanation you provided makes
> perfect sense.
>
> The only problem is that, with no code changes, it does not seem
> possible to generate a diameter acct rqst using diapwtst that, converted
> to a radius acct rqst, is acceptible by an external radius server
> because of the lack of an acct-session-id attribute.
>
> The -session_id parameter to diapwtst is for attribute 263, as noted,
> and does not get translated into a radius acct-session-id, which is
> fine, and makes sense. But there are no parameters available to
> diapwtst to be able to specify the acct-session-id (attribute 44) that
> does get converted. This means that there is no way to generate a
> radius request (that was converted from a diameter request) that
> contains an acct-sesssion-id field, which is required by a radius server
> to accept the accounting request.
>
> I understand there are workarounds, like hooks for example. I decided
> the easiest approach was to add code to diapwtst for a command line
> parameter for acct_session_id, that adds attribute 44 to a diameter
> accounting request/response. It's only a few lines of extra code, and
> works fine.
>
> So I would suggest (feel free to shoot me down here, if there's an
> easier way) that acct-session-id (44) be added to the command line
> options for diapwtst. Otherwise I don't see a way of generating a
> 'legal' accounting request (once converted) that contains an
> acct-session-id without code changes.
>
> I think that anyone who uses diapwtst and radiator to convert and send
> radius to a third party radius server will run into this problem.
>
> Thanks again,
> Blake
>
>
>
> -----Original Message-----
> From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au] On
> Behalf Of Hugh Irvine
> Sent: Wednesday, March 21, 2007 1:02 AM
> To: Blake Ulmer
> Cc: Radiator Mailinglist
> Subject: Re: (RADIATOR) accounting request Acct-Session-Id lost in
> conversion from diameter to radius
>
>
> Hello Blake -
>
> Further to this, you could use the PreHandlerHook available in the
> ServerDIAMETER clause to do whatever you wish.
>
> The PreHandlerHook is passed a pointer to the translated radius
> request as an arguement, and there is a reference in that radius
> request to the original Diameter request in $tp->{diameter_request}.
>
> See the code in "Radius/ServerDIAMETER.pm" and the example hooks in
> "goodies/hooks.txt".
>
> regards
>
> Hugh
>
> On 21 Mar 2007, at 10:57, Mike McCauley wrote:
> > Hello Blake,
> >
> > Thanks for your thoughtful comments.
> > The reason that copy_dia_to_radius_attrs works the way it does is
> > from our
> > interpretation of the Diameter RFCs.
> >
> > I would expect to see accounting session IDs in the Diameter Acct-
> > Session-Id
> > AVP (code 44), (which would be immediately converted to the RADIUS
> > Acct-Session-Id attribute).
> >
> > Session-ID (code 263) is a Diamater-specific thing, and would not
> > normally be
> > transferred to the Radius packet (as you have noted).
> >
> > Hope that helps.
> >
> > Cheers.
> >
> > On Wednesday 21 March 2007 08:52, Blake Ulmer wrote:
> >> Hello again,
> >>
> >> Thanks for the quick reply to my first posting (undefined
> >> Authenticator
> >> field converting from diameter to radius). I have another potential
> >> problem in the diameter to radius conversion, specifically for
> >> accounting packets.
> >>
> >> Again, my environment is 3.16 on RHEL4. I'm doing a diamter
> >> accounting
> >> request (using diapwtst) to radiator, which converts it to radius,
> >> and
> >> sends it off to my third party radius server. The radius server
> >> is not
> >> accepting the request, because Acct-Session-Id is not present.
> >>
> >> I specify -session_id <whatever> to diapwtst, and I can see the
> >> originating diameter request containing the session-id (if I don't
> >> specify anything, then I get a default session-id, but it's there).
> >> However, the converted radius acct request does not contain it.
> >>
> >> I dove into ServerDIAMETER.pm, and found that the
> >> copy_dia_to_radius_attrs method only converts a few specific
> >> attributes,
> >> and then anything with an attribute number below 256. The session-id
> >> field (ACODE_SESSION_ID) has a value of 263, which is why it isn't
> >> being
> >> converted. That set of ifs also has no plain old, "else", which
> >> is why
> >> there's no log message or anything about why it isn't converted,
> >> or that
> >> it isn't being converted.
> >>
> >> I have a somewhat kludgey fix I'm using, which is to simply add
> >> another
> >> if for the diameter ACODE_SESSION_ID, which copies $value into the
> >> packet for Acct-Session-Id, and that seems to work.
> >>
> >> I know that Acct-Session-Id is required by the radius RFC, and so I
> >> wonder why the attribute is only copied if the attribute number is
> >> less
> >> than 256? It seems either that number should be much larger, or a
> >> specific case needs to be entered for ACODE_SESSION_ID.
> >>
> >> Thank you again,
> >> Blake Ulmer
> >>
> >> Here's a snippet of the Acct-Session-Id not being translated (in an
> >> accounting request), for kicks:
> >>
> >> **************************************************************
> >> Tue Mar 20 18:37:05 2007: DEBUG: zulu.open.com.au <- testoriginhost
> >> recv_v1msg:
> >> Code: 271 (Accounting)
> >> Version: 1
> >> Flags: 0x80 (R)
> >> Application ID: 1 (Nasreq)
> >> Hop-to-Hop ID: 2
> >> End-to-End ID: 554696706
> >> Attributes:
> >> Session-Id: 64, 5,
> >> Origin-Host: 64, testoriginhost,
> >> Origin-Realm: 64, testoriginrealm,
> >> User-Name: 64, bob at hal9002.com,
> >> Called-Station-Id: 64, 123456789,
> >> Calling-Station-Id: 64, 987654321,
> >> NAS-Port: 64, 1234,
> >> Accounting-Record-Type: 64, START_RECORD,
> >> Accounting-Record-Number: 64, 12345,
> >> Tue Mar 20 18:37:05 2007: DEBUG: StateMachine::event R-Rcv-Message in
> >> state R-Open. Calling Process
> >> Tue Mar 20 18:37:05 2007: DEBUG: zulu.open.com.au Process
> >> Tue Mar 20 18:37:05 2007: DEBUG: Packet dump:
> >> *** Diameter request converted to Radius request ....
> >> Code: Accounting-Request
> >> Identifier: UNDEF
> >> Authentic: 1234567890123456
> >> Attributes:
> >> NAS-Identifier = "testoriginhost"
> >> User-Name = "bob at hal9002.com"
> >> Called-Station-Id = "123456789"
> >> Calling-Station-Id = "987654321"
> >> NAS-Port = 1234
> >> Acct-Status-Type = 1
> >>
> >> Tue Mar 20 18:37:05 2007: DEBUG: Handling request with Handler
> >> 'Realm=hal9002.com'
> >> Tue Mar 20 18:37:05 2007: DEBUG: Handling with Radius::AuthRADIUS
> >> Tue Mar 20 18:37:05 2007: DEBUG: Packet dump:
> >> *** Sending to 192.168.3.248 port 1813 ....
> >>
> >> Packet length = 93
> >> 04 01 00 5d e8 28 e8 a6 c7 39 60 1f 3f eb d6 1c
> >> cf 9c ac 40 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 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 28 06 00 00 00 01 29 06 00 00 00 00
> >> Code: Accounting-Request
> >> Identifier: 1
> >> Authentic: <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> >> Attributes:
> >> NAS-Identifier = "testoriginhost"
> >> User-Name = "bob at hal9002.com"
> >> Called-Station-Id = "123456789"
> >> Calling-Station-Id = "987654321"
> >> NAS-Port = 1234
> >> Acct-Status-Type = 1
> >> Acct-Delay-Time = 0
> >> **************************************************************
> >
> > --
> > Mike McCauley mikem at open.com.au
> > Open System Consultants Pty. Ltd Unix, Perl, Motif, C++,
> > WWW
> > 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://
> > www.open.com.au
> > Phone +61 7 5598-7474 Fax +61 7 5598-7070
> >
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP,
> > TLS,
> > TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.
> >
> > --
> > Archive at http://www.open.com.au/archives/radiator/
> > Announcements on radiator-announce at open.com.au
> > To unsubscribe, email 'majordomo at open.com.au' with
> > 'unsubscribe radiator' in the body of the message.
>
> 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?
--
Mike McCauley mikem at open.com.au
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au
Phone +61 7 5598-7474 Fax +61 7 5598-7070
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.
--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list