Wireshark-bugs: [Wireshark-bugs] [Bug 10323] New: MIPv6 Service Selection Identifier parse error
Date: Wed, 30 Jul 2014 12:15:01 +0000
Bug ID 10323
Summary MIPv6 Service Selection Identifier parse error
Classification Unclassified
Product Wireshark
Version 1.12.0
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Normal
Priority Low
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter ybnmts@gmail.com

Created attachment 12942 [details]
packet capture showing the erroneous Service selection identifier in the PBU
message

Build Information:
Version 1.12.0rc3 (v1.12.0rc3-0-ge14d5b6 from master-1.12)
--
When decoding the "Identifier" field under the "Service Selection" category in
the MIPv6 Proxy Binding Update(PBU) message, it looks like wireshark is
omitting the first character of the "identifier" which is actually sent.

If you refer to the attachement , in packet number 7 , under Mobility
options->Service Selection->Identifier , it displays "nternetims". But , when
looking at the hex view of the packet, we can see the full Identifier string
("internetims") displayed there.

The packet seems to be in accordance with the RFC
http://tools.ietf.org/html/rfc5149#section-3 .

When I looked into the latest code for this section, here's what I found in
"packet-mip6.c"
--------------------------------------------------------------------------------
/* 20 Service Selection Mobility Option [RFC5149]  */
#define MAX_APN_LENGTH 100

static void
dissect_mip6_opt_ssm(const mip6_opt *optp _U_, tvbuff_t *tvb, int offset,
             guint optlen, packet_info *pinfo _U_, proto_tree *opt_tree,
proto_item *hdr_item _U_ )
{
    int    len;
    guint8 str[MAX_APN_LENGTH+1];
    int    curr_len;

    /* offset points to tag(opt) */
    offset++;
    proto_tree_add_item(opt_tree, hf_mip6_opt_len, tvb, offset, 1,
ENC_BIG_ENDIAN);
    offset++;

    len = optlen - MIP6_SSM_SSM_OFF;

    /* 3GPP TS 29.275 version 10.5.0 Release 10, Table 5.1.1.1-2
     * Set to the EPS Access Point Name to which the UE
     * attaches the new PDN connection.
     * The encoding the APN field follows 3GPP TS 23.003
     * [12] subclause 9.1 but excluding the trailing zero byte.
     * The content of the APN field shall be the full APN with
     * both the APN Network Identifier and default APN
     * Operator Identifier being present as specified in 3GPP
     * TS 23.003 [12] subclauses 9.1.1 and 9.1.2
     * NOTE 4.
     * NOTE 4: The APN field is not encoded as a dotted string as commonly used
in documentation
     */

    if (len > 0) {
        /* init buffer and copy it */
        memset(str, 0, MAX_APN_LENGTH);
        tvb_memcpy(tvb, str, offset, len<MAX_APN_LENGTH?len:MAX_APN_LENGTH);

        curr_len = 0;
        while ((curr_len < len) && (curr_len < MAX_APN_LENGTH))
        {
            guint step    = str[curr_len];
            str[curr_len] = '.';
            curr_len     += step+1;
        }
        /* High light bytes including the first lenght byte, excluded from
str(str+1) */
        proto_tree_add_text(opt_tree, tvb, offset, len, "Identifier: %s",
str+1);
        proto_item_append_text(hdr_item, ": %s", str+1);
    }
}
-------------------------------------------------------------------------------
It looks like code is omitting the first character of the identifer(as seen in
""Identifier: %s", str+1);") , which seems to be inline with my observation.

Can anyone please have a look into this and let me know if I've mis-understood
the problem or if we have a bug here?

Thanks!
Vybhav


You are receiving this mail because:
  • You are watching all bug changes.