Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 1848] New WiMAX ASN Protocol (WMXA) Di
From: "Stephen Croll" <[email protected]>
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 - [email protected] and the proposed replacement: > TLV Type: MS NAI , TLV Length: 30 For reference, the full dissection of this TLV for the existing dissector is: TLV: MS NAI - [email protected] Type: MS NAI (105) Length: 30 Value: [email protected] and the proposed replacement: TLV Type: MS NAI , TLV Length: 30 TLV Type: 105 TLV Length: 30 TLV Value: [email protected] 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 , 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 , 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 , 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: 220.127.116.11 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 , 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 18.104.22.168 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 , 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