0

我正在为完整的 M3UA-SCCP-TCAP-MAP 堆栈（通过 SCTP）编写一个模拟器（用于学习目的）。到目前为止，M3UA+SCCP 堆栈都可以。

M3UA 基于 RFC 4666 2006 年 9 月
SCCP 基于 ITU-T Q.711-Q716
TCAP 基于 ITU-T Q.771-Q775

但是在解码 TCAP 部分时，我迷失了 dialogPortion。TCAP 是 asn.1 编码的，所以一切都是 tag+len+data。Wireshark 对它的解码与我的解码器不同。

消息是：62434804102f00676b1e281c060700118605010101a011600f80020780a1090607040000010005036c1ba1190201010201163011800590896754f282859106

基本上，我的消息被 BER 解码为

注：格式：hex(tag) + (BER 拆分为 CLS+PC+TAG 十进制) + hex(data)
 62 ( 64 32 2 )
     48 ( 64 0 8 ) 102f0067
     6b (64 32 11)
         28 ( 0 32 8 )
             06 ( 0 0 6 ) 00118605010101 OID=0.0.17.773.1.1.1
             a0 ( 128 32 0 )
                 60 ( 64 32 0 )
                     80 ( 128 0 0 ) 0780
                     a1 ( 128 32 1 )
                         06 ( 0 0 6 ) 04000001000503 OID=0.4.0.0.1.0.5.3
     6c ( 64 32 12 )
        ...

所以我可以看到包含 otid[8]、dialogPortion[11] 和 componentPortion[12] 的 begin[2] 消息。otid 和 ComponentPortion 被正确解码。但不是对话框部分。dialogPortion 的 ASN 未提及任何这些代码。更令人困惑的是，wireshark 以不同的方式对其进行解码（oid-as-dialogue 不在 dialogPortion 中，而是作为 otid 之后的一个字段，这与 ITU-T 文档中的描述不同——或者不是我所理解的）

Wireshark 解码交易能力应用部分
    开始
        源交易 ID
            编号：102f0067
        oid：0.0.17.773.1.1.1（id-as-dialogue）
        对话请求
            填充：7
            协议版本：80（版本1）
                1 ... .... =版本1：真
            应用程序上下文名称：0.4.0.0.1.0.5.3 (locationInfoRetrievalContext-v3)
        组件：1 件
           ...

我在 dialogPDU ASN 中找不到任何有关填充的参考。

有人可以指出我正确的方向吗？我想知道如何正确解码此消息

在这种情况下，DialoguePDU 格式应该很简单：

dialogue-as-id OBJECT IDENTIFIER ::=  {itu-t recommendation q 773 as(1) dialogue-as(1) version1(1)}

DialoguePDU ::= CHOICE {
  dialogueRequest   AARQ-apdu,
  dialogueResponse  AARE-apdu,
  dialogueAbort     ABRT-apdu
}

AARQ-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE {
  protocol-version          [0] IMPLICIT BIT STRING {version1(0)} DEFAULT {version1},
  application-context-name  [1]  OBJECT IDENTIFIER,
  user-information          [30] IMPLICIT SEQUENCE OF EXTERNAL OPTIONAL
}
4

2 回答 2

0

Wireshark 仍然是错误的:-)。但是……那是显示。它正确显示值 - 仅在错误的部分。由于更容易解码，可能是某种原因。

我缺少的是外部的定义[8]。DialoguePortion 被声明为 EXTERNAL ......所以现在一切都说得通了。

于 2015-07-09T19:20:04.493 回答
0

对于您的信息，我自己的解码器说：

    begin [APPLICATION 2] (x67) 
        otid [APPLICATION 8] (x4) =102f0067h
        dialoguePortion [APPLICATION 11] (x30) 
            EXTERNAL (x28) 
                direct-reference [OBJECT IDENTIFIER] (x7) =00118605010101h
                encoding:single-ASN1-type [0] (x17) 
                    dialogueRequest [APPLICATION 0] (x15) 
                        protocol-version [0] (x2) = 80 {version1 (0) } spare bits= 7
                        application-context-name [1] (x9) 
                            OBJECT IDENTIFIER (x7) =04000001000503h
        components [APPLICATION 12] (x27) 
            invoke [1] (x25) 
                invokeID [INTEGER] (x1) =1d (01h)
                operationCode [INTEGER] (x1) = (22) SendRoutingInfo
                parameter [SEQUENCE] (x17) 
                    msisdn [0] (x5) = 90896734f2h
                        Nature of Address: international number (1)
                        Numbering Plan Indicator: unknown (0)
                        signal= 9876432
                    interrogationType [3] (x1) = (0) basicCall
                    gmsc-Address [6] (x5) = 9062859107h
                        Nature of Address: international number (1)
                        Numbering Plan Indicator: unknown (0)
                        signal= 26581970

现在，wireshark 的填充 7 和我的备用位 = 7 都指的是协议版本字段，在 Q.773 中定义为：

AARQ-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE {
     protocol-version [0] IMPLICIT BIT STRING { version1 (0) }
     DEFAULT { version1 },
     application-context-name [1] OBJECT IDENTIFIER,
     user-information [30] IMPLICIT SEQUENCE OF EXTERNAL
     OPTIONAL }

BIT STRING 定义，仅将名称分配给前导位（version1）...其余（7 位）未命名，wireshark 将它们视为填充

于 2015-11-11T17:27:18.670 回答