[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1848


stephen.d.croll@xxxxxxxxx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stephen.d.croll@xxxxxxxxx




------- Comment #4 from stephen.d.croll@xxxxxxxxx  2007-10-08 00:39 GMT -------
(In reply to comment #2)
> A plugin for the WiMAX ASN Control Plane was recently checked in (see
> plugins/wimaxasncp in the current sources).
> 
> Could you take a look at it and confirm that they cover the same thing?  If so,
> is  it possible to merge both of these efforts in some way?
> 

*** This reply also posted to the developers list. ***

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.


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.