["Stephen Croll" <stephen.d.croll@xxxxxxxxx>]

Martin Mathieson wrote:

> Have you looked at this new submission in detail, or tried it out?

>Does it handle anything that is missing from the current one we have,
> or handle something in a better way?

> I don't actually work with WiMAX, and haven't asked colleagues who
> do to play with this new submission.  I was hoping that the original
> submitter would test the existing dissector and do a comparison for
> us.

BIAS NOTE: I'm the original submitter of the existing wimaxasncp
dissector.

It is not apparent to me what the advantages are of this proposed
replacement over the existing one.  The following are my observations
after a somewhat quick comparison.

In terms of display, there appears to be a difference in strategy and
possibly in completeness.  In the existing dissector, I endeavored to
display the decoded values, or at least as much that will reasonably
fit, on each root node.  I did this to avoid having the user "drill
down" into a node (generally a TLV) to get the semantic meaning of the
node wherever possible.  For example, in the header, the existing
dissector displays the (unexpanded) flags as:

  > Flags: T - 0000 0010 = 0x02

and the proposed replacement displays:

  > Flags: 2

With the existing dissector, it should be readily apparent that the
T-bit is set without having to expand the node.

For reference, the complete header shown by the existing dissector is:

  WiMAX ASN Control Plane Protocol
      Version: 1
      Flags: T - 0000 0010 = 0x02
          Bit #6 is set: T - Source and Destination Identifier TLVs
      Function Type: HO Control (2)
      OP ID: Request/Initiation (001. .... = 1)
      Message Type: HO_Req (...0 0100 = 4)
      Length: 264
      MSID: 00:00:00_00:00:01 (00:00:00:00:00:01)
      Reserved: 0x00000000
      Transaction ID: 0x2c52
      Reserved: 0x0000

and the proposed replacement:

  WMXA Protocol
      Version: 1
      Flags: 2
          .... ...0 = Flags Rbit: False
          .... ..1. = Flags Tbit: True
      Function Type: HO Control (2)
      OP ID and Message Type: 36
          000. .... = OP ID: 0
          ...0 0100 = Message Type: 4
      Length: 264
      MSID: 00:00:00_00:00:01 (00:00:00:00:00:01)
      Reserved: 0
      Transaction ID: 11346
      Reserved: 0

Further note that the proposed replacement incorrectly (and
incompletely) decodes the OP ID and Message Type fields.  The actual
raw value is 0x24 (decimal 36).  The proposed replacement displays the
correct value 36, but incorrectly decodes the bits.  Furthermore, it
does not seem to show the string values of these fields
(Request/Initiation and HO_Req).

Another example is the MS NAI TLV.  The existing dissector displays:

  > TLV: MS NAI - mobile1@xxxxxxxxxxxxxxxxxxxxxx

and the proposed replacement:

  > TLV Type: MS NAI [105], TLV Length: 30

For reference, the full dissection of this TLV for the existing
dissector is:

  TLV: MS NAI - mobile1@xxxxxxxxxxxxxxxxxxxxxx
      Type: MS NAI (105)
      Length: 30
      Value: mobile1@xxxxxxxxxxxxxxxxxxxxxx

and the proposed replacement:

  TLV Type: MS NAI [105], TLV Length: 30
      TLV Type: 105
      TLV Length: 30
      TLV Value: mobile1@xxxxxxxxxxxxxxxxxxxxxx

Another difference is in enumeration displays.  The existing dissector
shows both the string and value in the Type and Value fields:.

  TLV: Serving/Target Indicator - Serving
      Type: Serving/Target Indicator (182)
      Length: 1
      Value: Serving (0)

Compare to the proposed replacement:

  TLV Type: Serving/Target Indicator [182], TLV Length: 1
      TLV Type: 182
      TLV Length: 1
      TLV Value: Serving

The existing dissector displays all TBD TLVs by default as hex.  The
value can be selected and highlighted in the bottom hex display window:

  TLV: EAP Payload - TBD
      Type: EAP Payload (62)
      Length: 46
      Value: 0101002E0157656C636F6D652E004E41495265616C6D733D...

The proposed replacement does not provide a selectable value field:

  TLV Type: EAP Payload [62], TLV Length: 46
      TLV Type: 62
      TLV Length: 46

Erroneous TLVs have the same issue.  According to spec, the following
TLV should have a fixed length of 20 bytes.  The existing dissector
displays:

  TLV: FA-HA Key - 000102030405060708090a0b0c0d0e0f1011
      Type: FA-HA Key (66)
      Length: 18
      Value: 000102030405060708090A0B0C0D0E0F1011

And the replacement has no selectable value field.  It does display an
error message (a plus), but it is not an expert mode thing:

    TLV Type: FA-HA Key [66], TLV Length: 18
        TLV Type: 66
        TLV Length: 18, Illegal Length.

In general, most bit field displays seem wrong.  For example, the spec
(release 1.1.0, July 11, 2007) defines the Authorization Policy TLV
as:

  5.3.2.21 Authorization Policy
    Type                21
    Length in octets    2
    Value               8-bit bitmask representing HO Authorization Policy.
                        * Bit #0 = RSA authorization
                        * Bit #1 = EAP authorization
                        * Bit #2 = Authenticated-EAP authorization
                        * Bit #3 = HMAC supported
                        * Bit #4 = CMAC supported
                        * Bit #5 = 64-bit Short-HMAC
                        * Bit #6 = 80-bit Short-HMAC
                        * Bit #7 = 96-bit Short-HMAC
                        * Bits #8-15 Reauthentication Policy (TBD)

     Description        This parameter is used to indicate authentication
                         mode (single EAP, double EAP or both).

                        In MS Security History TLV, it indicates the
                        capability negotiated between ASN and MS.

     Parent TLV          MS Info

Note that bit #0 is the most significant bit (network order).

The existing dissector produces this:

  TLV: Authorization Policy - 0x0212
      Type: Authorization Policy (21)
      Length: 2
      Value: 0000 0010 0001 0010 = 0x0212
          Bit #6 is set: 80-bit Short-HMAC
          Bit #11 is set: Reauthentication Policy (TBD)
          Bit #14 is set: Reauthentication Policy (TBD)

The proposed replacement:

  TLV Type: Authorization Policy [21], TLV Length: 2
      TLV Type: 21
      TLV Length: 2
      TLV Value: 0x0212,  EAP authorization,  CMAC supported,  Unknown
          .... .010 = TLV Value: EAP authorization (0x02)
          ...1 0... = TLV Value: CMAC supported (0x02)
          000. .... = TLV Value: Unknown (0x00)

Another example is the Reservation Action TLV.  The spec defines it as:

  2 5.3.2.151 Reservation Action
    Type                 151
    Length in octets     2

    Value                The Action field is a 16 bit vector with the
                         following meaning for each bit being set to "1":
                        * Bit 15 (0x0001) = Create service flow
                        * Bit 14 (0x0002) = Admit service flow
                        * Bit 13 (0x0004) = Activate service flow
                        * Bit 12 (0x0008) = Modify service flow
                        * Bit 11 (0x000A) = Delete service flow
                        * Bits 0 - 10 = Undefined

                        More than one of bits 13-15 MAY be set to 1 at
                        the same time (for instance, create &
                        admit, or create/admit/activate/ modify a
                        service flow).

   Description          Identifies the requested resource reservation action

   Parent TLV           SF Info

The existing dissector has:

  TLV: Reservation Action - 0x0007
      Type: Reservation Action (151)
      Length: 2
      Value: 0000 0000 0000 0111 = 0x0007
          Bit #13 is set: Activate service flow
          Bit #14 is set: Admit service flow
          Bit #15 is set: Create service flow

And the replacement (with incorrect TLV name):

  TLV Type: Reserved Action [151], TLV Length: 2
      TLV Type: 151
      TLV Length: 2
      TLV Value: 0x0007,  Create service flow.,  Admit service flow.,
 Activate service flow.,  Modify service flow.
          .... .... .... ...1 = TLV Value: Create service flow. (1)
          .... .... .... ..1. = TLV Value: Admit service flow. (1)
          .... .... .... .1.. = TLV Value: Activate service flow. (1)
          .... .... ...0 ..1. = TLV Value: Modify service flow. (1)

Please note that I have not looked at the filter fields.  Perhaps the
proposed replacement does this better than the existing one.

--
Steve Croll