From a Telco vendor I have some proprietary Diameter AVPs of type Unsigned16, with associated a list of possible values. When I try to define a list of possible values for this AVP in "dictionary.xml" in the following way I get the following error:
Note that if I try instead to define this proprietary AVP as type Enumerated, I have then an error in the decoding, as the the lenght of the AVP is 16 and not 32 as it is required by the type enumerated. Do you know if there's a working syntax for Diameter to use in dictionary.xml to define a list of possible values for a type Unsigned16 AVP? asked 10 Aug '17, 03:45  rpiccinini |
2 Answers:
I have zero knowledge of diameter, but looking at the dissector source code, unsigned16 is not a supported type, only 32 and 64. answered 10 Aug '17, 04:07  grahamb ♦ |
There's nothing in the Wireshark Diameter dissector, Diameter dictionary reading code, or Diameter dictionary files that supports Unsigned16. Unknown types are treated as OctetString, so Wireshark only shows the raw octets of the value; it doesn't show it as a 16-bit big-endian integral value. Neither RFC 3588 nor RFC 6733 list Unsigned16 as a "Basic AVP Data Format" - or as a "Derived AVP Data Format". Section 1.3.2 "Creating New AVPs" of RFC 6733 says
However, RFC 6735 repeatedly refers to an AVP data format "Unsigned16". Any AVP data format Wireshark doesn't explicitly recognize is treated as OctetString, and the Internet-Draft draft-frascone-xml-dictionary-00, "Diameter XML Dictionary", which is the specification for the XML format for a Diameter dictionary, says:
with no mention of any other types - neither Unsigned16 nor OctetString. So you can't currently use an enum element for your AVP with Wireshark. We could add "Unsigned16" as a (quasi-)Basic AVP Data Format, and allow AVPs with that format to have an enum element. Given that at least one AVP mentioned in an RFC uses it, that might be a reasonable thing to do, although, on the other hand, a draft(?) of 3GPP TS 32.299 used Unsigned16 for SIP-Request-Timestamp-Fraction and SIP-Response-Timestamp-Fraction AVPs, but Alcatel-Lucent made a change request to make it Unsigned32 because Unsigned16 was "Not Diameter Compliant" as it was "not defined in RFC 3588 as diameter base format", and, in fact, the change was made. So is the AVP length for that AVP 14? (I'm assuming from the presence of a vendor-id that the V flag is set and the Vendor-ID is present in the AVP.) answered 15 Aug '17, 14:44  Guy Harris ♦♦ so is the AVP length for that AVP 14? (I'm assuming from the presence of a vendor-id that the V flag is set and the Vendor-ID is present in the AVP.) That's correct, the AVP length is 14. Also your other assumptions are correct. Below an example of how one of this AVPs is decoded using the Unsigned16 type in dictionary.xml. Clearly only the raw value is shown, as it is not possible to define a list. Beside this specific AVP there are also some others from the same proprietary specification (references 3GPP TS 32.299, v8.4.0 and IETF RFC 4006) that are using an Unsigned16 type.
(18 Aug '17, 03:33) rpiccinini Unsigned16 is derived from OctetString AVP base format. It holds 16 bit unsigned value, in network byte order. According to the 32-bit boundary alignment rules of RFC 3588 for values of type OctetString, the AVP value will be followed by 2 zero-valued bytes of padding to ensure that the next AVP will start in a 32-bit boundary. (18 Aug '17, 05:59) rpiccinini |
Actually if I do not try to define a list, the type Unsigned16 is correctly supported by dictionary.xml and all the proprietary AVPs are correctly decoded. But clearly without the list it is just shown the raw value.