Ethereal-dev: Re: [Ethereal-dev] 3GPP RADIUS VSAs (according to TS 29.061 V4.8.0)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Rui Carmo <rui.carmo@xxxxxxxxx>
Date: Fri, 5 Dec 2003 00:50:28 +0000

On 5 Dec 2003, at 00:20, Guy Harris wrote:

On Dec 4, 2003, at 3:02 PM, Rui Carmo wrote:

I've recently had need to parse some of the 3GPP RADIUS VSAs (and at least identify the rest), so a colleague of mine dug up the specs and I coded the following patch. It identifies all 18 of the currently defined 3GPP VSAs and prints out the values we needed (mostly IPv4 addresses so far). I've left out IPv6 (for now, since I can't test this yet) and left UTF-8 data unparsed (no real way to test it either).

Is there some reason why there are THE3GPP_SGSN_ADDRESS and THE3GPP_GGSN_ADDRESS type values, rather than just making those TLV's have the type RADIUS_IP_ADDRESS? (That enum isn't supposed to be an enum of every single attribute, it's supposed to be an enum of attribute types.)

Not really, no. But the enum code block wasn't really commented (so I couldn't know what it was supposed to be or the semantics of its use), and after dealing with 3GPP specs for a few years, believe me when I say you _want_ to discern even between labels to the same thing... They're that picky.

Similarly, perhaps there should be a RADIUS_UTF8_STRING type for all the UTF-8 strings and a RADIUS_IPV6_ADDRESS type for IPv6 addresses.

Maybe. I did not even attempt to find how to deal with either UTF-8 or IPv6 inside Ethereal, since I could not test those fields. Nevertheless, I tried to make it obvious where those ocurred, so that someone more in tune with Ethereal might build on the VSA definitions I provided and pick up where I left off. Do bear in mind that I fixed what I needed and little more, and that I never touched Ethereal code before, so I'm not aware of any guidelines...

Also, THE3GPP_CHARGING_ID is just like RADIUS_INTEGER4 except that it's printed with "%d" rather than "%u" - is it really a *signed* 32-bit integer? If not, it should probably just be RADIUS_INTEGER4.

It is not defined within the standard as anything other than an octet tuple (and as far as I know it is only an opaque "handle", without any meaningful numeric value). I might check the spec again, but that is another field I cannot test at this point since it is not filled in by any network element.

Regards,

Rui Carmo
http://the.taoofmac.com