(RADIATOR) PacketCable Structure and Radiator.
Hugh Irvine
hugh at open.com.au
Tue Jun 1 20:01:52 CDT 2004
Hello Ricardo -
Unfortunately for this type of complex vendor specific, there has to be
special code added to "Radius/Radius.pm".
The routine that does this is "sub unpack()" and you will find some
examples for other vendor specifics therein.
You will probably want to run radiusd with trace 5 to see the hex
packet dumps to help with debugging.
As mentioned, if you would send us your dictionary definitions and
additional code, we will roll it all in for the next release.
BTW - for the vendor specific dictionary definitions you should prefix
the attribute names with something like "PC_EM_Header" just to avoid
any possibility of name clashes with other vendor definitions.
thanks and 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.
--
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