Wireshark-bugs: [Wireshark-bugs] [Bug 1848] New WiMAX ASN Protocol (WMXA) Dissector
Date: Mon, 8 Oct 2007 00:39:47 +0000 (GMT)
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.
- Prev by Date: [Wireshark-bugs] [Bug 1798] packet-d*.c display filter fields incorrectly named.
- Next by Date: [Wireshark-bugs] [Bug 1886] Conversation exposes "Dissector bug, protocol NCP"
- Previous by thread: [Wireshark-bugs] [Bug 1848] New WiMAX ASN Protocol (WMXA) Dissector
- Next by thread: [Wireshark-bugs] [Bug 1894] New: Add IMPS 1.2 and IMPS 1.3 protocols support
- Index(es):