Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 1848] New WiMAX ASN Protocol (WMXA) Di
From: "Stephen Croll" <stephen.d.croll@xxxxxxxxx>
Date: Sun, 7 Oct 2007 08:52:08 -0500
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
- Prev by Date: [Wireshark-dev] Packets are filtered and dissected but ethertype unknown?
- Next by Date: Re: [Wireshark-dev] Packets are filtered and dissected but ethertypeunknown?
- Previous by thread: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 1848] New WiMAX ASN Protocol (WMXA) Dissector
- Next by thread: [Wireshark-dev] Hosting Our Project on Wireshark Site
- Index(es):