MIPv6 Service Selection Identifier parse error
This issue was migrated from bug 10323 in our old bug tracker.
Original bug information:
Reporter: Vybhav
Status: RESOLVED FIXED
Product: Wireshark
Component: Dissection engine (libwireshark)
OS: Windows 7
Platform: x86
Version: 1.12.0
Attachments:
pmipb6_pbu_error.pcapng: packet capture showing the erroneous Service selection identifier in the PBU message
Activity
Created attachment 12942
packet capture showing the erroneous Service selection identifier in the PBU message
Build Information:
Version 1.12.0rc3 (v1.12.0rc3-0-ge14d5b6e 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! Vybhavadded libwireshark oswindows version1.12 labels
-
According to 3GPP 23.003: "Each label is coded as a one octet length field followed by that number of octets coded as 8 bit ASCII characters. Following RFC 1035 [19] the labels shall consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following RFC 1123 [20], the label shall begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not significant. The APN is not terminated by a length byte of zero." So the first byte is supposed to be the length of the label (understand the string before the first '.') and not the first character of the APN. What equipment performed this encoding? it looks wrong to me.
-
Thanks for your comment Pascal. The spec that you refer to looks to be the spec for APN in case of LTE. However, we are referring to service selection field in PMIPv6 messages which use RFC 5149 as reference. In the RFC also, the service selection is defined as follows: "Identifier: A variable-length encoded service identifier string used to identify the requested service. The identifier string length is between 1 and 255 octets. This specification allows international identifier strings that are based on the use of Unicode characters, encoded as UTF-8 [3], and formatted using Normalization Form KC (NFKC) as specified in [4]. 'ims', 'voip', and 'voip.companyxyz.example.com' are valid examples of Service Selection option Identifiers." Here, there is no additional octet at the beginning of the identifier field. Please correct me if I'm mistaken, but I believe the PBU is sent as per RFC5149 and the wireshark code also refers to this RFC(in the comments for the function). -Vybhav -
Well I guess the RFC encoding is the correct one in 3GPP TS 29.275 version 11.9.0 Release 11 it says: Service Selection Mobility Option M 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. IETF RFC 5149 [11] NOTE 4: The APN field is not encoded as a dotted string as commonly used in documentation Which is a bit ambigious in my opinion... Regards Anders -
(In reply to comment #5) > Well I guess the RFC encoding is the correct one in 3GPP TS 29.275 version > 11.9.0 Release 11 it says: > > > Service Selection > Mobility Option > M 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. > IETF RFC 5149 [11] > > NOTE 4: The APN field is not encoded as a dotted string as commonly used in > documentation > > Which is a bit ambigious in my opinion... > > Regards > Anders My (probably wrong) understanding was that the note meant that there was a single label, but still with a length in the first byte. But I agree we could also understand it this way :) -
Change 3461 had a related patch set uploaded by Pascal Quantin: MIPv6: fix dissection of Service Selection Identifier
-
Change 3461 merged by Anders Broman: MIPv6: fix dissection of Service Selection Identifier
-
Change 3467 had a related patch set uploaded by Pascal Quantin: MIPv6: fix dissection of Service Selection Identifier
-
Change 3467 merged by Pascal Quantin: MIPv6: fix dissection of Service Selection Identifier
-
Change 3472 had a related patch set uploaded by Pascal Quantin: MIPv6: fix dissection of Service Selection Identifier
-
Change 3472 merged by Pascal Quantin: MIPv6: fix dissection of Service Selection Identifier
-
Interestingly, bug #10492 (closed) provides a capture that uses the 3GPP way to encode the Service Identifier. So it is no more properly decoded with up to date Wireshark versions.