Wireshark-bugs: [Wireshark-bugs] [Bug 9622] sendRoutingInfoForSMResp Phase 1 decode problem (GSM
Comment # 3
on bug 9622
from Luke Mewburn
I think you're right about the schema.
The ASN.1 for RoutingInfoForSM-Arg and RoutingInfoForSM-Res was changed in a
non-backwards-compatible manner between version 1 and subsequent versions.
E.g. from ETS 300 599: December 2000 (GSM 09.02 version 4.19.1)
--v--
RoutingInfoForSM-Res::= SEQUENCE {
imsi IMSI,
locationInfoWithLMSI [0] LocationInfoWithLMSI,
mwd-Set [2] BOOLEAN OPTIONAL,
-- mwd-Set must be absent in version greater 1
...}
LocationInfoWithLMSI ::= SEQUENCE {
locationInfo LocationInfo,
lmsi LMSI OPTIONAL,
...}
--^--
>From 3GPP TS 29.002 V12.3.0 (2013-12) (in Wireshark as MAP-SM-DataTypes.asn)
--v--
RoutingInfoForSM-Res ::= SEQUENCE {
imsi IMSI,
locationInfoWithLMSI [0] LocationInfoWithLMSI,
extensionContainer [4] ExtensionContainer OPTIONAL,
...,
ip-sm-gwGuidance [5] IP-SM-GW-Guidance OPTIONAL }
LocationInfoWithLMSI ::= SEQUENCE {
networkNode-Number [1] ISDN-AddressString,
lmsi LMSI OPTIONAL,
extensionContainer ExtensionContainer OPTIONAL,
...,
gprsNodeIndicator [5] NULL OPTIONAL,
-- gprsNodeIndicator is set only if the SGSN number is sent as the
-- Network Node Number
-- [ .. etc ...]
--^--
As you can see, the structure of LocationInfoWithLMSI differs in what I think
is incompatible between the v1 and v3 versions.
Wireshark appears to have a workaround for v1 RoutingInfoForSM-Arg in
asn1/gsm_map/GSMMAP.asn as RoutingInfoForSM-ArgV1.
I think the fix would be to extend GSMMAP.asn to have v1 definitions for
RoutingInfoForSM-Res and LocationInfoWithLMSI, and modify
packet-gsm_map-template.c dissect_returnResultData() handling for case 45 to be
similar to dissect_invokeData()'s version-specific handling.
You are receiving this mail because:
- You are watching all bug changes.