Subject: [Sigtran] Help decoding parameter Diagnostic Information

From: Fernandes, António Carlos, VF-PT<[email-masked]>
Date: Thu, 18 Jan 2007 15:52:36 -0000

Hello everyone,
i'm trying to interconnect two different vendors over M3UA and during the process of ASP activation my SG is responding to some incoming messages (DAUD) with "Unexpected Message" which I think is due to the fact that the ASP is still marked as inactive from the SG side and no ASPActivate message has been received yet. 
In the error message sent by the SG there is an optional parameter "Diagnostic Information" which is not decoded by my protocol analyzer.
I have searched the RFCs for the format of this message but could not find any relevant information. 
Can someone help me on how to decode this information?

Best Regards
António Fernandes

---------------------------------------------------------------------------
This message may contain confidential information or privileged material, and is intended only for the individual(s) named. If you are not in the named addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

Vodafone (Portugal)
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Sergey Mikhailov" <[email-masked]>
Date: Thu, 18 Jan 2007 23:23:59 +0700

Antonio,

Section 3.8.1 of RFC 4666 says:

"If the Unexpected message contained Routing Contexts, the Routing Contexts SHOULD be included in the Error message."

and

"When included, the optional Diagnostic Information can be any information germane to the error condition, to assist in identification of the error condition.  The Diagnostic Information SHOULD contain the offending message."

There's no strict way to use the Diagnostic Information parameter (hence it may not have the recommended contents, to be decoded as expected).
But, when satisfying the recommendations above, it includes the offending message (DAUD in your case).

Regards,
Sergey Mikhailov.

  ----- Original Message ----- 
  From: Fernandes, Antonio Carlos, VF-PT 
  To: [email-masked] 
  Sent: Thursday, January 18, 2007 10:52 PM
  Subject: [Sigtran] Help decoding parameter Diagnostic Information

  Hello everyone,

  Best Regards
  AntСnio Fernandes

  --------------------------------------------------------------------------------------------

  Vodafone (Portugal)

------------------------------------------------------------------------------

---

From: Fernandes, António Carlos, VF-PT<[email-masked]>
Date: Thu, 18 Jan 2007 16:43:18 -0000

Sergey,

I cannot guarantee that the offending message is present in the Diagnostic Information because I only see hexadecimal characters inside that parameter.

The analyzer decodes the length in bytes but nothing more.

My question is if there is some way to decode this hex message.

Regards,

António

From: Sergey Mikhailov [mailto:[email-masked]] 
Sent: quinta-feira, 18 de Janeiro de 2007 16:24
To: Fernandes, António Carlos, VF-PT
Cc: SIGTRAN
Subject: Re: [Sigtran] Help decoding parameter Diagnostic Information

António,

and

 

Regards,

Sergey Mikhailov.

	----- Original Message ----- 

	From: Fernandes, António Carlos, VF-PT <mailto:[email-masked]>  

	To: [email-masked] 

	Hello everyone,
	
	Best Regards
	AntСnio Fernandes

	Vodafone (Portugal)

________________________________

Vodafone (Portugal)

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 18 Jan 2007 17:45:01 +0100

Hi,

the M3UA RFC says:

    Diagnostic Information: variable length

       When included, the optional Diagnostic information can be any
       information germane to the error condition, to assist in
       identification of the error condition. The Diagnostic information
       SHOULD contain the offending message.

This means that the format is not specified in a way that you can  
dissect
it. Wireshark, for example, shows this field simply a byte vector.

What you can do is to try to guess what is in there. I would expect
something at the beginning followed by a M3UA message. You should
try to figure out where this message begins and dissect it by hand.

Best regards
Michael

On Jan 18, 2007, at 4:52 PM, Fernandes, António Carlos, VF-PT wrote:

> Hello everyone,
> i'm trying to interconnect two different vendors over M3UA and  
> during the process of ASP activation my SG is responding to some  
> incoming messages (DAUD) with "Unexpected Message" which I think is  
> due to the fact that the ASP is still marked as inactive from the  
> SG side and no ASPActivate message has been received yet.
> In the error message sent by the SG there is an optional parameter  
> "Diagnostic Information" which is not decoded by my protocol analyzer.
> This message may contain confidential information or privileged  
> material, and is intended only for the individual(s) named. If you  
> are not in the named addressee you should not disseminate,  
> distribute or copy this e-mail.
>
> Please notify the sender immediately by e-mail if you have received  
> this e-mail by mistake and delete this e-mail from your system.
>
>
> E-mail transmission cannot be guaranteed to be secure or error-free  
> as information could be intercepted, corrupted, lost, destroyed,  
> arrive late or incomplete, or contain viruses. The sender therefore  
> does not accept liability for any errors or omissions in the  
> contents of this message which arise as a result of e-mail  
> transmission. If verification is required please request a hard- 
> copy version.
>
>
> Vodafone (Portugal)
>

---

From: Fernandes, António Carlos, VF-PT<[email-masked]>
Date: Thu, 18 Jan 2007 17:35:56 -0000

Hello Michael,
Thx for the tip!
I manage to dissect part of the message.
The SG basically sends in the diagnostic information filed some sort of header followed by the exact message that cause the ERR (a copy of the DAUD message received by the SG in my case).
The only thing I could not decode was the header:

00001F3500000000

Best regards,
António

-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: quinta-feira, 18 de Janeiro de 2007 16:45
To: Fernandes, António Carlos, VF-PT
Cc: [email-masked]
Subject: Re: [Sigtran] Help decoding parameter Diagnostic Information

Hi,

the M3UA RFC says:

Best regards
Michael

Vodafone (Portugal)

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 18 Jan 2007 19:56:48 +0100

On Jan 18, 2007, at 6:35 PM, Fernandes, António Carlos, VF-PT wrote:

> The SG basically sends in the diagnostic information filed some  
> sort of header followed by the exact message that cause the ERR (a  
> copy of the DAUD message received by the SG in my case).
That is implementation dependent. You have to ask your vendor...
If he provides that information, I might be able to integrate that
into Wireshark...
>> --------------------------------------------------------------------- 
>> -
>> ----------------------
>>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 18 Jan 2007 12:15:27 -0700

Michael,

Michael Tuexen wrote:                      (Thu, 18 Jan 2007 19:56:48)
> If he provides that information, I might be able to integrate that

A parameter that cannot be machine decoded isn't very useful is it?
It was my understanding when we put the passages in the UA RFCs that
the Diagnostic SHOULD contain at least the first 40 bytes of the
offending message and _just_ the offending message (without proprietary
header fields or other sundry undecodable information).

My point being that although RFC 4666 says the Diagnostic "SHOULD contain
the offending message," we didn't mean `amoungst other things'.  Any
implementation that does not put the message first in the field, and as
the only information in the field, is not following the recommendation.

Supporting passages:

So, in RFC 3331:

   The optional Diagnostic information can be any information germane to
   the error condition, to assist in the identification of the error
   condition.  In the case of an Invalid Version Error Code the
   Diagnostic information includes the supported Version parameter.  In
   the other cases, the Diagnostic information SHOULD be the first 40
   bytes of the offending message.

In RFC 3332

RFC 4666 goes farther:

   The "Unsupported Message Class" error is sent if a message with an
   unexpected or unsupported Message Class is received.  For this error,
   the Diagnostic Information parameter MUST be included with the first
   40 octets of the offending message.

   The "Unsupported Message Type" error is sent if a message with an
   unexpected or unsupported Message Type is received.  For this error,
   the Diagnostic Information parameter MUST be included with the first
   40 octets of the offending message.

      When included, the optional Diagnostic Information can be any
      information germane to the error condition, to assist in
      identification of the error condition.  The Diagnostic Information
      SHOULD contain the offending message.  A Diagnostic Information
      parameter with a zero length parameter is not considered an error
      (this means that the Length field in the TLV will be set to 4).

RFC 3868

3.9.7.  Diagnostic Information

   The Diagnostic Information can be used to convey any information
   relevant to an error condition, to assist in the identification of
   the error condition.  In the case of an Adaptation Layer Identifier
   or Traffic Handling Mode, the Diagnostic Information includes the
   received parameter.  In the other cases, the Diagnostic information
   may be the first 40 bytes of the offending message.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/