Wireshark-bugs: [Wireshark-bugs] [Bug 7042] The MSISDN is not seen correctly in GTP packet
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7042
--- Comment #11 from Guy Harris <guy@xxxxxxxxxxxx> 2012-04-10 18:12:15 PDT ---
Is the "+" in the MSISDN just a display convention? If so, perhaps we should,
as per an item in the Wireshark development wishlist:
http://wiki.wireshark.org/Development/Wishlist
add an FT_TBCD field type, with a display prefix or something of that sort
pointed to by its hf[] entry, and, in a display filter for an FT_TBCD field, if
the value it's being compared with begins with the same display prefix, strip
it off, so that, for example, you could do either
gtp.msisdn == "+966590381372"
or
gtp.msisdn == "966590381372"
and have them work in the same fashion. If there's more than one
interpretation of 0xA through 0xE, that could be specified by an ENC_ argument
for proto_tree_add_item().
BTW, a comment in the Q.825 ASN.1:
http://www.itu.int/ITU-T/formal-language/itu-t/q/q825/1998/Q825-CDR-ASN1Module.html
says
-- TBCD-STRING ::= OCTETSTRING
-- This type (Telephony Binary Coded Decimal String) is used to represent
digits from 0
-- through 9, *, #, a, b, c, two digits per octet, each digit encoded 0000
to 1001 (0 to 9),
-- 1010 (*) 1011(#), 1100 (a), 1101 (b) or 1110 (c); 1111 (end of pulsing
signal-ST); 0000 is
-- used as a filler when there is an odd number of digits.
-- The most significant address signal is sent first. Subsequent address
signals are sent in
-- successive 4-bit fields.
However, unless there's an explicit digit count, or if 1111 is an
end-of-digit-string value, I don't see how 0000 can be used as a filler, as I
don't see how it can be distinguished from the digit 0.
The entry in the development wishlist says
-- TBCD-STRING ::= OCTET STRING
-- This type (Telephony Binary Coded Decimal String) is used to
-- represent several digits from 0 through 9, *, #, a, b, c, two
-- digits per octet, each digit encoded 0000 to 1001 (0 to 9),
-- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used
-- as filler when there is an odd number of digits
-- bits 8765 of octet n encoding digit 2n
-- bits 4321 of octet n encoding digit 2(n-1) +1
which speaks of 1111 as the filler. That matches ETSI TS 100 974 V7.15.0
(2004-03), a/k/a 3GPP TS 09.02 version 7.15.0 Release 1998 (GSM MAP).
However, the Dgt_tbcd in packet-ansi_map.c is
static dgt_set_t Dgt_tbcd = {
{
/* 0 1 2 3 4 5 6 7 8 9 a b c d e */
'0','1','2','3','4','5','6','7','8','9','?','B','C','*','#'
}
};
which is a different encoding - maybe the ANSI encoding differs from the ITU-T
encoding here, but it looks as if that might be ANSI T1.114-1988, which costs
USD 300, which I'd rather not spend if I didn't have to. :-)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
