WiMAX ASN 控制协议 (WIMAXASNCP) ​

历史 ​

协议依赖 ​

• UDP：WIMAXASNCP 使用 UDP 作为其传输协议。WIMAXASNCP 流量的知名 UDP 端口是 2231。

示例流量 ​

Wireshark ​

WIMAXASNCP dissector 基于 WiMAX Forum Network Architecture（Stage 3: Detailed Protocols and Procedures），Release 1.0.0，2007 年 3 月 28 日规范，并且基本可用。有些 TLV 没有完全解码，但如果 dissector 已知其类型，则显示值将默认使用十六进制。

WiMAX 规范差异 ​

消息类型解码 ​

该规范将消息类型 MS_Attachment_Req、MS_Attachment_Rsp 和 MS_Attachment_Ack 定义为具有函数类型 Data Path Control：

| WiMAX Forum Network Architecture | Function: Data Path Control (3) | MS_Attachment_Req (13) | MS_Attachment_Rsp (14) | MS_Attachment_Ack (15)

该插件还将消息类型 MS_Attachment_Req、MS_Attachment_Rsp 和 MS_Attachment_Ack 识别为具有函数类型 MS State：

| Wireshark WIMAXASNCP Plugin | Function: MS State (9) | MS_PreAttachment_Req (6) | MS_PreAttachment_Rsp (7) | MS_PreAttachment_Ack (8)

此外，该 dissector 还识别函数类型 Session。额外的消息类型如下：

| Wireshark WIMAXASNCP Plugin | Function: Session (11) | Session_Release_Req (1) | Session_Release_Rsp (2) | Session_Release_Ack (3) | Session_Failure_Rpt (4) | Session_Failure_Rsp (5)

额外 TLV ​

WIMAXASNCP dissector 可识别以下额外 TLV。

| 类型 | 名称 | 值 | 1136 | Control Plane Indicator | 0 = Success, 1 = Failure | 1228 | IM Auth Indication | 0 = Success, 1 = Failure

限制 ​

与 802.16e-2005 相关的 TLV ​

该 dissector 目前无法对与 802.16e-2005 相关的 TLV 进行默认十六进制转储之外的解码。供参考，这些 TLV 如下：

| 类型 | 名称 | 说明 | 49 | DCD Setting | 复合类型，如 [802.16e-2005] 第 11.1.7 节所规定。 | 72 | Full DCD Setting | 复合类型，如 [802.16e-2005] 第 11.1.7 节所规定。 | 73 | Full UCD Setting | 复合类型，如 [802.16e-2005] 第 11.1.7 节所规定。 | 195 | UCD Setting | 复合类型，如 [802.16e-2005] 第 11.1.7 节所规定。 | 74 | Global Service Class Change | IEEE802.16e 中定义的 Global Service Class Name。 | 81 | IDLE Mode Retain Info | 按 802.16e 中的方式编码。 | 118 | Paging Cycle | 在 paging group 中传输 paging message 的周期（与 802.16e 对齐）。 | 169 | SAID | 按照 802.16 的 SAID 定义。

定义不清晰的 TLV ​

这些 TLV 在规范中定义不清晰，并被解码为十六进制转储。

| 类型 | 名称 | 说明 | 41 | Data Integrity Info | 没有长度、值或描述。 | 78 | HO Process Optimization | 值：表示 HO Process Optimization 代码的 8 位整数，但没有描述。 | 104 | MS Mobility Mode | 未定义数值基数。值给出为 00、01、10、11。我推测这是二进制，但其他 TLV 会明确地定义为二进制（例如 0b11）或十六进制（0x11）。 | 167 | R3 Operation Status | 未定义数值基数。见上文描述。 | 121 | Paging Start/Stop | 长度定义为 1，但没有提供值。 | 122 | PC Relocation Indication | 长度定义为 1，但没有提供值。 | 148 | Relocation Response | 值定义为 boolean，但规范中未定义 boolean。还存在另外两个 boolean TLV，但它们对成功和失败的定义不同。参见 Anchor PC Relocation Request Response (14)，其将 0xFF 定义为 accept，将 0x00 定义为 refuse；以及 LU Result Indicator (90)，其将 0 定义为 success，将 1 定义为 failure。 | 149 | Relocation Success Indication | 值定义为 boolean，但规范中未定义 boolean。见上文描述。 | 155 | ROHC/ECRTP Context ID | 长度和值描述为 TBD。 | 181 | Service Authorization Code | 没有长度、值或描述。

这些 TLV 在规范中定义不清晰，但已尝试对其进行一些解码。

| 类型 | 名称 | 说明 | Dissector 行为 | 82 | IP Destination Address and Mask | 有歧义。以 octets 表示的长度被描述为 Nx8（IPv4）或 Nx32（IPv6），但此函数并不总是能区分 IPv4 和 IPv6。例如，如果 length = 32，那么它是 N=4（4x8）的 IPv4，还是 N=1（1x32）的 IPv6？ | 假定那些可以表示 IPv6 地址和掩码列表的长度确实表示 IPv6 地址和掩码列表。 | 84 | IP Source Address and Mask | 有歧义。见上文描述。 | 同上。 | 0xFFFF | Vendor Specific TLV | vendor specific information field (VSIF) 的格式定义不清晰。它似乎是复合类型，因为规范声明 vendor ID field 应是嵌入在 VSIF 内的第一个 TLV。然而，vendor ID 显示为 24 位值。这是否意味着该字段是 24 位？如果是，对齐/填充如何处理？ | 将 vendor ID 解码为无填充的 24 位值，并将其余部分转储为十六进制。

其他 TLV ​

以下 TLV 只是尚未实现。除 EAP payload 可能例外，所有这些 TLV 的 dissect 都应该相当直接。

| 类型 | 名称 | 说明 | 48 | DCD/UCD Configuration Change Count | | 60 | DL PHY Quality Info | | 61 | DL PHY Service Level | 以十六进制、十进制（或其他格式）显示？ | 62 | EAP Payload | 困难？也许可以借用 RADIUS 版本。 | 85 | IP TOS/DSCP Range and Mask | | 94 | Media Flow Type | | 174 | SBC Context | | 197 | UL PHY Quality Info | | 198 | UL PHY Service Level | 以十六进制、十进制（或其他格式）显示？

首选项设置 ​

（XXX 添加指向会影响 PROTO 如何被 dissect 的首选项设置的链接。）

示例捕获文件 ​

显示过滤器 ​

可在显示过滤器参考中找到 WIMAXASNCP 显示过滤器字段的完整列表

仅显示基于 WIMAXASNCP 的流量：

 wimaxasncp

捕获过滤器 ​

捕获时不能直接过滤 WIMAXASNCP 协议。不过，如果你知道所使用的 UDP 端口（见上文），则可以按该端口过滤。

仅捕获默认端口（2231）上的 WIMAXASNCP 流量：

 udp port 2231

外部链接 ​

• WiMAX Forum http://wimaxforum.org

讨论 ​

于 2020-08-11 23:27:26 UTC 从 https://wiki.wireshark.org/WIMAXASNCP 导入

原始页面图片 ​

相关 Wireshark Wiki 页面 ​

• Wireshark Wiki 首页Home · 入门与使用
• UDPUDP · 协议参考