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