[Florent Drouin <florent.drouin@xxxxxxxxxxxxxxxxx>]

   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