ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] First cut at H.450 dissector

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

From: Guy Harris <gharris@xxxxxxxxx>
Date: Tue, 23 Sep 2003 23:42:39 -0700
On Tue, Sep 23, 2003 at 11:42:13AM -0700, Guy Harris wrote:
> 
> On Sep 23, 2003, at 4:58 AM, Graeme Reid wrote:
> >   The only known problem with it so far is that an invoke Id in a 
> > return result or return error of >32k
> > will be displayed as a negative number.
> 
> Well, the constrained invokeId is an unsigned integer (FT_UINT32), but 
> the other invokeID is signed (FT_INT32), so values with the uppermost 
> bit set will be treated as negative numbers.
> 
> The first of those is handled by "dissect_per_constrained_integer()", 
> which treats the integer as unsigned.  The latter is handled by 
> "dissect_per_integer()", which treats it as signed; I don't have any of 
> the ASN.1 specs handy, so I don't know whether there needs to be, for 
> example, a "dissect_per_unsigned_integer()" routine.

Well, X.680 doesn't seem to have any unsigned integer type, it just has
a signed integer type.

SNMP defines the unsigned Counter and Gauge types as

                  Counter ::=  
                      [APPLICATION 1]   
                          IMPLICIT INTEGER (0..4294967295)

                  Gauge ::=
                      [APPLICATION 2]
                          IMPLICIT INTEGER (0..4294967295)

Perhaps I'm misreading it, but I infer from X.690 that you might need 5
data bytes to represent that - it sounds as if the value 4294967295
requires 33 bits, given the "and then reducing this value by the
numerical value assigned to bit 8 of the first octet if that bit is set
to one" in clause 8.3.3 of X.690 (BER, DER), so the uppermost bit of a
positive integer has to be 0, not 1.

X.691 (PER), however, has both "2's-complement-binary-integer encoding"
and "non-negative-binary-integer encoding".  Constrained integers are,
it appears, encoded as an index into the range of allowed values, which
are always non-negative.  Unconstrained integers are (as per 10.8)
encoded as a 2's-complement-binary-integer, i.e. they're signed.

The page at

	http://www.itu.int/ITU-T/asn1/database/itu-t/h/h450.1/1998/Remote-Operations-Apdus.html

says

  ReturnResult{OPERATION:Operations} ::= SEQUENCE {
    invokeId
      InvokeId
        (CONSTRAINED BY {-- must be that for an outstanding operation -- } !
         RejectProblem:returnResult-unrecognizedInvocation)
        (CONSTRAINED BY {-- which returns a result -- } !
         RejectProblem:returnResult-resultResponseUnexpected),
    result
      SEQUENCE {opcode
                  OPERATION.&operationCode({Operations})
                    (CONSTRAINED BY {-- identified by invokeId -- } !
                     RejectProblem:returnResult-unrecognizedInvocation),
                result
                  OPERATION.&ResultType
                    ({Operations}{@.opcode} !
                     RejectProblem:returnResult-mistypedResult)} OPTIONAL
  }
  (CONSTRAINED BY { -- must conform to the above definition --} !
   RejectProblem:general-mistypedPDU)

and "InvokeID" links to

	http://www.itu.int/ITU-T/asn1/database/itu-t/h/h450.1/1998/Remote-Operations-Apdus.html#Remote-Operations-Apdus.InvokeId

which says

	InvokeId ::= INTEGER

so that's a signed value, as it's unconstrained.

Is the uppermost bit of the value 1? If so, then it's negative, and
should be displayed as such.