https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5434
--- Comment #16 from Anders Broman <anders.broman@xxxxxxxxxxxx> 2011-08-25 22:29:14 PDT ---
Hi,
That's because I have added sub dissection of some AVP:s where the
content of the AVP:s octet string is dissected most of that is
packet-diameter_3GPP.c, this particular avp is dissected in packet-gtpv2.c,
that dissection is failing, either because the content of the packet is wrong
according to the spec(version used) or a bug in the dissector.
Perhaps we should have a prefreence wether to do sub dissection or not.
The first byte of the octet string is "Geographic Location Type" the rest is
"Geographic Location"
3GPP TS 29.061
:
Geographic Location Type filed is used to convey what type of location
information is present in the 'Geographic
Location' field. The geographic location type values and coding are as defined
in TS 29.060 [24].
Geographic Location fieled is used to convey the actual geographic information
as indicated in the Geographic Location
Type. The coding of this field is as specified in TS 29.060 [24].
Geographic Location Type and Geographic Location fields are Octet String type.
3GPP TS 29.061 version 10.3.0 Release 10
Geographic Location Type field is used to convey what type of location
information is present in the 'Geographic
Location' field. For GGSN, the Geographic Location Type values and coding are
as defined in 3GPP TS 29.060 [24].
For P-GW, the Geographic Location Type values and coding are defined as
follows:
0 CGI
1 SAI
2 RAI
3-127 Spare for future use
128 TAI
129 ECGI
130 TAI and ECGI
131-255 Spare for future use
In this trace 3GPP-User-Location-Info: 160a0052f02008fe0081
the first byte is 0x16 which seems wrong, on the other hand that's a undefined
value and shouldn't be disscted.
Regards
Anders
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
