Hi,
Thank's again for the correction.
I do not see the warning anymore, but the display of the Facility is not
bellow the facility itself, but at the end of the tree.
It's not a problem, but it looks strange..
I found an other problem with a recent correction of the "Forward SM"
message.
The message for MAP v2, has not the same name as for MAP v3 (a bug was
opened for this).
With the new ASN1 file, we should not use the old definition
"gsm_old_GSMMAPOperationLocalvalue_vals", but the new one, else the
correction is lost, and we see mo-forwardSM instead of forwardSM as
message name.
<<
const gchar* gsm_map_opr_code(guint32 val) {
switch (val) {
case 44: /*mt-forwardSM*/
case 46: /*mo-forwardSM*/
if (application_context_version == 3) {
return val_to_str(val, gsm_map_V3_opr_code_strings, "Unknown
GSM-MAP (%u)");
}
/* Else use the default map operation translation */
default:
return val_to_str(val, *gsm_map_opr_code_strings*, "Unknown GSM-MAP
opcode (%u)");
break;
}
}
>>
In the attached sample of forwardSM, you can see the Forward-SM, and two
additional problems of decoding for "SMS Deliver Report". These
problems of decoding for sm-RP-UI are not new, because there are related
to the packet-gsm_sms.c module.
What is new, with the new ASN1 file, is that the sm-RP-UI is not decoded
for the mo/mt-forwardSM.
I think the gsmmap.cnf should be updated to call the sms dissector, as
it is done for ForwardSM.
And at least :-), could you update the Unix Makefile to use gsmmap.cnf
and not gsm_map.cnf.
Thanks in advance.
Best regards
Florent
Anders Broman wrote:
Hi,
I Believe I fixed all exept:
- and one with a Facility with Forward CUG info. For this problem, this
is only a display problem, as the information is correctly decoded, but
a Warning is displayed at the end of the decoding.
I see no warning :(
Regards
Anders
Attachment:
ForwardSMS.cap
Description: Binary data
