使用Wireshark进行SMPP协议分析
本文将向您展示如何使用Adobe Campaign Classic的Wireshark执行SMPP协议分析。
描述 description
环境
Adobe Campaign Classic (ACC)
问题/症状
了解如何使用Wireshark分析SMPP流量。
大多数高吞吐量短信服务中心(SMS-C)与SMPP协议版本3.4兼容。此协议允许发送短信并接收有关这些短信投放的信息。 SMPP 协议以 PDF 文档形式记录在互联网上的 SMPP 协议规范 v3.4 中。
本文不能替代本规范：它提供了有关如何解释协议规范并将其与Wireshark显示匹配的实用技巧，帮助解决Adobe Campaign和SMS-C合作伙伴之间的问题。
由于SMPP协议包含许多部分，留给实施团队来解释，因此不同的SMS-C之间存在差异。
解决问题时，请始终联系 SMS-C 合作伙伴以获取信息或帮助您仔细检查所获得的信息。如果 SMS-C 回复错误，您的 SMS-C 合作伙伴将是告诉您为什么回复错误的最佳人选。 如果您使用的是 SMPP 模拟器而不是连接到真正的 SMS-C，您应该使用源代码（或调试器）来了解正在发生的事情。
分辨率 resolution
不使用Wireshark捕获网络流量
如果您无法直接访问机器，则可能需要使用命令行工具（如tcpdump）进行捕获。 如果您已经知道连接的 TCP 端口，请放置正确的过滤器以避免捕获所有流量。 以下是tcpdump命令行示例，用于捕获到 outfile.pcap 的端口12345：
tcpdump -i any -w outfile.pcap tcp port 12345
然后可以在Wireshark中打开文件 outfile.pcap 以供进一步分析。
本主题假设您熟悉Wireshark的基础知识：捕获数据包、定义简单过滤器、读取数据包详细信息。 简要介绍请见howtogeek — 如何使用Wireshark捕获、过滤和Inspect数据包。
在Wireshark中过滤掉SMPP流量，有三个重要的特点：
-
在SMS-C的端口上使用显示过滤器。 例如，如果SMS-C使用端口10000，请使用以下过滤器：
tcp.port == 10000 -
要按电话号码或文本内容隔离数据包，请使用具有以下设置的搜索功能：
-
使用 关注TCP流 工具隔离您正在处理的流。
关闭弹出的红色/蓝色文本窗口，因为它只对与 SMPP 无关的文本协议有用。
-
SMPPProtocol
该协议在TCP上运行并且是完全二进制的，这意味着特殊工具如Wireshark（或十六进制编辑器）需要解密流的内容。
流由独立的 PDU 组成：每个 PDU 都是一条消息，包含命令、状态、序列号和基于命令的其他信息。
由于 TCP 作为流协议的性质，一个 TCP 数据包可能包含多个 PDU，而 PDU 可能跨越 2 个或更多 TCP 数据包。Wireshark将正确地重新组装PDU，因此对于Wireshark用户来说，该过程几乎透明。
以下是发送MT，然后接收SR时PDU通过网络的示例：
注意：可在SMPP规范（SMPP命令集）的第5.1.2.1节中找到标准命令列表。
SMPP响应
SMPP协议要求所有命令都由响应PDU确认：
BIND_TRANSMITTER由 BIND_TRANSMITTER_RESP 确认，SUBMIT_SM 由 SUBMIT_SM_RESP 等确认。
响应超时，通常为10、30或60秒。 响应可能包含肯定确认（命令_状态= 0）或错误（请参阅标准错误列表的SMPP规范中的5.1.3 command_status、表5-2）。 大多数时候，这些响应是立即的，并且不会达到响应超时。
确保区分 SMPP 响应错误和 SR 错误代码：相同的错误代码在响应错误或 SR 错误字段中可能意味着不同的内容。 报告错误代码时，您必须非常小心找到它的位置，因为该值的含义取决于其上下文。
SMPP连接初始化
SMPP连接从使用TCP连接开始。 然后由campaign发送BIND操作，由BIND RESP确认。 SMPP规范的第4.1节中介绍了这些操作（BIND操作）。
绑定操作执行登录/密码检查并交换有关平台名称、版本和规范中描述的其他字段的信息。
注意：登录可见于system_id字段。
在Campaign中，启动MT传输时应看到 BIND_TRANSMITTER 数据包，在 nlsm s 触发MO/SR连接时应看到 BIND_RECEIVER 数据包。
发射器、接收器和收发器： Campaign Classic 的 SMPP 连接器在单独的发送器/接收器模式下工作：有两个 TCP 连接，一个用于发送 MT，另一个用于接收 MO 和 SR。请注意，TCP连接始终由Campaign启动，即使对于接收器模式也是如此。
SMPP 还提供收发器模式，但此模式未在 Campaign Classic 的 SMPP 连接器中实施。
SMPP 连接器使用多个并行连接来传输 MT。 由于连接器的设计方式，这是无法控制的。
正在接收MO
当接收方绑定后，SMS-C可以随时发送MO。 MO使用 DELIVER_SM PDU发送，已清除 esm_clas s 的第2-5位（通常，esm_class 将只是0）。
DELIVER_SM PDU必须由具有相同 序列号 的 DELIVER_SM_RESP PDU快速回复。
发送MT
要发送MT，必须成功绑定发射器。 首先，检查绑定过程是否已成功执行。
MT在 SUBMIT_SM PDU中发送。 SMS-C应快速通过 SUBMIT_SM_RESP PDU回复：此响应包比较特殊，因为它包含了SMS-C的数据库中消息的ID（在与SMS-C合作伙伴通话时始终包含此ID，可帮助他更快地找到消息）。 此 ID 将出现在 SR 中，并且是将 MT 与其对应的 SR 匹配的唯一方法。
字段 registered_delivery（在规范的第5.2.17节中描述）向SMS-C指示是否为这个特定的MT请求了SR。 如果您没有收到特定消息的SR，请检查该字段在 SUBMIT_SM PDU中是否正确设置。
MT 的编码
注意：短信编码是一个复杂的主题，有许多陷阱和各种实施。
好的做法是在出现编码问题时始终联系SMS-C合作伙伴。 您的SMS合作伙伴对支持的编码和由于其技术平台的限制可能适用的特殊规则有准确的了解。 让他们检查您发送给他们的内容以及他们发送给您的内容。 这是成功且稳定互连的唯一途径。
短信消息使用特殊的 7 位编码，通常称为 GSM7 编码。 参考Wikipedia GSM 03.38（英文）。
在SMPP协议中，GSM7文本将扩展为每个字符8位，可促进故障排除。 SMS-C 在发送到移动设备之前会将其打包成每个字符 7 位。 这意味着 SMS 的 short_message 字段在 SMPP 帧中可能长达 160 个字节，而在移动网络上发送时限制为 140 个字节（最高有效位被简单地丢弃）。
如果出现编码问题，请检查以下重要事项：
- 首先，确保您知道哪些字符属于哪种编码。 GSM7 因其部分支持变音符号（重音符号）而臭名昭著。 尤其是在法语中，é 和 è 是 GSM7 的一部分，但 ê、â 或 ï 不是。 说到西班牙语，情况也好不到哪里去。
- 带有 cedilla (ç) 的 C 在 GSM7 字母表中仅以大写形式出现，但有些移动设备以小写或“智能”大小写呈现：一般建议是完全避免这种情况并移除 cedilla（法语仍然可读）或切换到 UCS-2。
- 请勿在短信中使用 ASCII，除非 SMS-C 合作伙伴明确要求：这种编码会浪费空间，因为它有 8 位字符且覆盖范围比 GSM7 少。
- 并非始终支持 Latin-1：在尝试使用 Latin-1 之前，请检查与您的 SMS-C 合作伙伴的兼容性。
- Adobe Campaign Classic 连接器不支持国家语言转换表。 必须改用 UCS-2。
- UCS-2 和 UTF-16 经常在手机混合使用。 对于发送表情符号和其他 UCS-2 中不存在的少见字符的人来说，这是一个问题。
- Wireshark不支持GSM7编码：特殊字符显示不正确。 如果您需要检查 GSM7 字符串是否正确编码，您必须将十六进制代码与 GSM7 表进行比较。
data_coding 字段告诉您使用哪种编码。 唯一的问题是值 0 表示规范中的默认 SMS-C 编码，但通常它表示 GSM7。 与SMS-C 合作伙伴确认哪种编码与data_coding = 0关联(Adobe Campaign仅支持GSM7进行data_coding = 0)。
消息的大小上限取决于其编码。 下表总结了所有相关信息：
用户数据标头(UDH)
UDH（用户数据标头）是添加到SMS文本中的小型二进制标头。 它们可以触发特殊功能，例如短信连接、国家语言转换表、徽标/图像（很少使用）或 WAP 推送。
由于 UDH 是文本字段（short_message SMPP 字段）的一部分，因此它缩短了 SMS 的有效大小。 例如，连接的短信UDH 将消耗每个短信部分的 6 个字节（即 6 个真正的 8 位字节，而不是 7 位字符），为每个消息部分仅留出 152 个 7 位字符的空间。
维基百科上有关于“用户数据标头”和“关联SMS”（英文）的好文章。
要知道 short_message 是否包含 UDH，请检查 esm_class 的第 6 位和第 7 位（参见规范的第 5.2.12 节）。 Wireshark在界面中解析UDH并提供准确的信息。
在上面的截图中，您可以看到消息字段中的用户数据标头(1)、UDH中包含的信息(2)以及一些不属于数据包但由Wireshark计算得出的额外信息(3)：短消息正文字段特别有趣，因为它包含由Wireshark重组的完整消息。
正在接收SR
当接收方绑定后，SMS-C可以随时发送SR。 SR是使用DELIVER_SM PDU发送的，该PDU设置了 esm_class 的第2-5位。
DELIVER_SM PDU必须由具有相同 序列号 的 DELIVER_SM_RESP PDU快速回复。 要查找与此SR匹配的MT，请搜索具有相同ID的 SUBMIT_SM_RESP。 例如，这是与SR匹配的MT：
只有在MT中设置了 registered_delivery 字段时才发送SR。
注意： Adobe Campaign Classic SMPP连接器不处理在 SUBMIT_SM_RESP 数据包前到达的SR。 规范没有明确禁止这种行为，但认为此行为是不良行为（这意味着消息在发送之前已经被接收）。 如果您经常遇到这种情况，请让您的SMS-C合作伙伴修复其平台。
正在解密SR 的short_message字段
SR PDU的文本字段具有SMPP协议规范的附录B中描述的特殊编码。 不幸的是，这种格式只是一种建议，而不是协议的一部分，尽管大多数 SMS-C 或多或少地尊重这种格式。
您应该直接向SMS-C合作伙伴索取其实施的文档，并仔细检查它是否与您在Wireshark中看到的内容相匹配。 很多时候，SMS-C 的实施者甚至不了解他们的实施，这会导致问题和误解。 如果对此字段有任何疑问（尤其是错误代码），请随时向 SMS-C 合作伙伴寻求帮助。
基本格式如下所示：
id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE
Text:........
这些是阅读上述行的一般准则：
- 该ID与匹配的MT的 SUBMIT_SM_RESP 中已发送的相同。
- 您可以忽略文本字段中的问题：此字段已被Campaign忽略，因为如果SMS使用其他编码而不是纯字母数字ASCII发送，则它是无用的、不可靠的，甚至可能完全不可读。 这是正常行为。
- 字段名称不区分大小写（例如，id： sub： Text：也可以记为ID： SUB： text：）。
- dlvrd 字段通常不可靠，除非由SMS-C合作伙伴记录在案。
- 日期可能有任何时区，这使得它们实际上毫无用处，或者它们完全是错误的，因为远程服务器的时钟已关闭。
- stat 字段可能具有除附录B中定义的值之外的其他值。使用常识和SMSC合作伙伴的文档来理解其含义。
- err 字段完全依赖于SMS-C，并且大部分时间由SMS-C合作伙伴记录。 通常，代码 000 表示成功，而任何其他代码都表示错误。 该字段通常是数值，但也可以是十六进制。
同一MT的多个SR
有些SMS-C会为同一个MT发送多个SR以跟踪MT在网络中的进展。 这几乎是无用的，因为大多数时候客户端只想知道何时收到消息（这通常是最后一个 SR）。
如有疑问，请仅处理从SMS-C收到的最新SR以查找消息的状态。
SMPP窗口
由于操作和响应是异步的，您可以通过在等待响应之前发送多个操作PDU来优化传输速率。 没有回复的消息数称为窗口。
最大窗口为4的传输示例：
当前实现不控制窗口，并期望远程SMS-C足够快以处理MT。