(RADIATOR) PacketCable Structure and Radiator.
Hugh Irvine
hugh at open.com.au
Wed Jun 2 01:49:07 CDT 2004
Hello Ricardo -
Also on this topic - an alternative approach is to use a PreClientHook
to parse the VSA and add some pseudo-attributes to the incoming
request. You will find an example hook that does something quite
similar in the file "goodies/hooks.txt".
regards
Hugh
On 2 Jun 2004, at 03:24, Ricardo Martinez wrote:
> Hugh.
> Thanks for your reply. I found in the PDF document all the
> attributes that i was looking for. So, now i have "half" of my
> Accounting-Request working. Now, Radiator, can recognize the typical
> VSA
> attributes, for example Called-Party-Number, Calling-Party-Number, etc.
> This attributes are defined as string or integer according to the
> document
> (PKT-SP-EM), but in some cases this attributes are defined as a "Data
> Structure". A Data Structure contains more attributes inside.
> I defined the attribute "EM_Header" as all the possible types that
> radiator
> can handle : String, integer, data, binary, abinary, but it seems that
> radiator can't understand this attribute.
>
> *** Received from xxx.xxx.xxx.xxx port 11555 ....
> Code: Accounting-Request
> Identifier: 16
> Authentic: <127><138>:<181><240>u!<248><14><14><201><28><154><252><0>%
> Attributes:
> NAS-IP-Address = xxx.xxx.xxx.xxx
> Acct-Status-Type = Alive
> EM_Header = <0><1><196>g%<14>
> 123461-050000<0><0><0><11><0><1><0><1>
> 123461-050000<0><0><0><18>20040601105350.144<0><0><0><0><128><0><5><0>
> Direction_indicator =
> MTA_Endpoint_Name = "aaln/2 at ata1.metropolis-inter.com"
> Calling_Party_Number = " 5629589100"
> Called_Party_Number = " 5629589200"
> Routing_Number = " 5629589200"
>
> Wed Jun 2 12:54:34 2004: NOTICE: Request from unknown client
> 200.30.192.164: ignored
> Wed Jun 2 12:54:35 2004: DEBUG: Packet dump:
>
> A "decoded" EM_Header attribute must be as this :
>
> Code: Accounting Request (4)
> Packet identifier: 0x26 (38)
> Length: 187
> Authenticator
> Attribute value pairs
> t:NAS IP Address(4) l:6, Value:10.32.32.40
> t:Acct Status Type(40) l:6, Value:Interim Update(3)
> t:Vendor Specific(26) l:84, Vendor:CableLabs(4491)
> Event Message Version ID: 1
> BCID
> Timestamp: 1041973756
> Element ID: 40
> Time Zone: DST: 0, Offset: -070000
> Event Counter: 25
> Event Message Type: Call_Answer (15)
> Element Type: CMS (1)
> Element ID: 40
> Time Zone: DST: 0, Offset: -070000
> Sequence Number: 52
> Event Time: 2003010714 929.431
> Status: 0x00000000
> .... .... .... .... .... .... .... ..00 = Status: No Error
> (0x00000000)
> .... .... .... .... .... .... .... .0.. = Event Origin: Trusted
> Element (0x00000000)
> .... .... .... .... .... .... .... 0... = Event Message Proxied: Not
> proxied(0x00000000)
> Priority: 0
> Attribute Count: 3
> Event Object: 0
> t:EM_Header Data structure(1) l:78, Value:
>
> So, i'm loosing all the information in the EM_Header.
>
> Is there a way to "read" or "decode" this attribute in the Radiator
> Server?
>
> Thanks in advance
>
> Best Regards.
>
> Ricardo Martínez.
>
>> -----Mensaje original-----
>> De: Hugh Irvine [SMTP:hugh at open.com.au]
>> Enviado el: Jueves, 27 de Mayo de 2004 07:54 p.m.
>> Para: Ricardo Martinez
>> CC: 'radiator at open.com.au'
>> Asunto: Re: (RADIATOR) PacketCable Structure and Radiator.
>>
>>
>> Hello Ricardo -
>>
>> Radiator can certainly deal with these requests - all that is required
>> is the correct VSA definitions being added to the dictionary.
>>
>> This search:
>>
>> http://www.cablelabs.com/search/htsearch.html?config=public;
>> words=radius%20attribute;page=1
>>
>> gives the following document:
>>
>> PacketCable Event Messages Specification (PKT-SP-EM-I09-040402)
>>
>> which lists the VSA's in table 36 on page 65 of the document (page 75
>> of the PDF).
>>
>> You can add the VSA's to the Radiator dictionary with any text editor
>> and you will find many examples of VSA's in the dictionary already.
>>
>> As you will see from the debug, the vendor specific number for
>> PacketCable is 4491 as you rightly point out below.
>>
>> Once you get these VSA's working we will be happy to add them to the
>> standard Radiator dictionary if you send us a copy.
>>
>> regards
>>
>> Hugh
>>
>>
>> On 28 May 2004, at 02:52, Ricardo Martinez wrote:
>>
>>> Hello.
>>> I'm trying to receive and proccess RADIUS packets from a PacketCable
>>> structure with Radiator. Radiator must act as a RKS Server which
>>> receive
>>> Event Message from the Packet Cable network. These PacketCable Event
>>> Message are encapsulating in RADIUS packet. I made a simple test,
>>> and
>>> defined Radiator as my primary RKS server in my PacketCable network,
>>> so all
>>> the RADIUS packets are sent to the Radiator.
>>>
>>> I observed that the RADIUS packet arrived to the Radiator, and decode
>>> all
>>> the first part of the packet..
>>>
>>> Code: Accounting Request (4)
>>> Packet identifier: 0x25 (37)
>>> Length: 187
>>> Authenticator
>>> Attribute value pairs
>>> t:NAS IP Address(4) l:6, Value:10.32.32.40
>>> t:Acct Status Type(40) l:6, Value:Interim Update(3)
>>>
>>> Then Radiator it seems don't understand the next part of the message
>>> and
>>> send messages like the Attribute 3, 4, 5 are not in the dictionary.
>>> Even
>>> don't recognize the vendor 4491 (CableLabs). Unfortanately i don't
>>> have the
>>> "real" error messages from Radiator, but i have a Radius packet from
>>> a
>>> PacketCable Structure.
>>>
>>> Code: Accounting Request (4)
>>> Packet identifier: 0x25 (37)
>>> Length: 187
>>> Authenticator
>>> Attribute value pairs
>>> t:NAS IP Address(4) l:6, Value:10.32.32.40
>>> t:Acct Status Type(40) l:6, Value:Interim Update(3)
>>> t:Vendor Specific(26) l:84, Vendor:CableLabs(4491)
>>> Event Message Version ID: 1
>>> BCID
>>> Timestamp: 1041973760
>>> Element ID: 41
>>> Time Zone: DST: 0, Offset: -070000
>>> Event Counter: 26
>>> Event Message Type: Call_Answer (15)
>>> Element Type: MGC(1)
>>> Element ID: 41
>>> Time Zone: DST: 0, Offset: -070000
>>> Sequence Number: 51
>>> Event Time: 2003010714 929.431
>>> Status: 0x00000000
>>> .... .... .... .... .... .... .... ..00 = Status: No Error
>>> (0x00000000)
>>> .... .... .... .... .... .... .... .0.. = Event Origin: Trusted
>>> Element
>>> (0x00000000)
>>> .... .... .... .... .... .... .... 0... = Event Message Proxied: Not
>>> proxied
>>> (0x00000000)
>>> Priority: 0
>>> Attribute Count: 3
>>> Event Object: 0
>>> t:EM_Header Data structure(1) l:78, Value:
>>> t:Vendor Specific(26) l:32, Vendor:CableLabs(4491)
>>> Timestamp: 1041973756
>>> Element ID: 41
>>> Time Zone: DST: 0, Offset: -070000
>>> Event Counter: 25
>>> t:Related_Call_Billing_Correlation_ID(13) l:26, Value:
>>> t:Vendor Specific(26) l:28, Vendor:CableLabs(4491)
>>> t:Charge_Number(16) l:22, Value:" 3036613880"
>>> t:Vendor Specific(26) l:11, Vendor:CableLabs(4491)
>>> t:Financial Entity ID(49) l:5, Value:"440"
>>>
>>> As you can see is not very different from a "normal" radius packet.
>>> My
>>> question is: Can Radiator handle a packet like this.?. Has someone
>>> work
>>> with a PacketCable structure and Radiator. ?
>>> Where i can find the VSA's from PacketCable structure and how can i
>>> define
>>> them in the dictionary file?
>>>
>>> A lots of question as you can see.
>>>
>>> Thanks in advance.
>>>
>>> Best regards
>>>
>>>> Ricardo.
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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 included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>>
>> --
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
>> -
>> 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.
>>
>
>
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.
--
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