Wireshark-bugs: [Wireshark-bugs] [Bug 10323] New: MIPv6 Service Selection Identifier parse error
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.