On Fri, Dec 05, 2003 at 12:50:28AM +0000, Rui Carmo wrote:
> 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),
I've added a comment.
> 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.
Yes, but as that enum is used only to control how the item is formatted,
you don't want to distinguish between them in that case. It's
sufficient to give each one its own entry in
"radius_vendor_3gpp_attrib". (Ultimately, as much as possible of the
stuff in packet-radius.c should probably come from a file read at
startup time, rather than requiring packet-radius.c to be changed in
order for it to know about new attributes.
I made the ones that are IP addresses use type RADIUS_IP_ADDRESS.
> > 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.
I've added a RADIUS_IP6_ADDRESS type and used that for the IPv6 address
attributes.
> > 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).
TS 29.061 V5.7.0 says "Charging ID value: 32 bits unsigned integer". I
made it RADIUS_INTEGER4.
Checked in, with the aforementioned changes.