企业官网建设流程全解析

德思特基站模拟器这类设备，光能把小区开起来不算完，真正让你定位接入失败、呼叫异常、参数配置错误的，往往是配套协议分析。这篇第三篇实操教程，我专门把 Wireshark 的功能演示拆开讲一遍：基站模拟器跑通之后，Wireshark 到底能从哪些位置把协议消息抓出来，又该怎么通过过滤、解码和信令流程判断问题。

适合看这篇的人，是已经接触过基站模拟器，或者正在做终端接入、注册、呼叫类测试的工程师。如果你只是装了 Wireshark 还没想明白抓什么，这篇也能帮你建立一套排查思路。Wireshark 本身不难，难的是你得先搞清楚数据源在哪里，再决定用什么过滤器、看哪一层消息。下面按我实际测试的流程顺序来写。

1. 先想清楚：基站模拟器联调时，Wireshark 到底在抓什么

1.1 别把“空口射频”和“协议信令”混在一起

很多第一次接触基站模拟器的人，会默认 Wireshark 能直接抓空口信号。实际不是这样。Wireshark 是协议分析工具，不是频谱仪，也不是射频接收机。它能分析的，是已经转成数据包形式的协议消息，而不是天线口上的无线波形。

德思特基站模拟器这类设备，通常会在控制软件内部生成完整的协议栈信令。当测试终端接入模拟器时，模拟器会把“收到什么消息”“回复什么消息”“消息里携带哪些信元”记录下来。这些记录如果以 pcap 文件导出，或者通过某个网络接口实时输出，Wireshark 就能直接分析。

所以抓包之前，先确认一件最重要的事：你的 Wireshark 数据来源到底是什么。

常见有三种来源：

• 模拟器控制软件自带的抓包入口，直接把内部信令输出成 pcap 或 pcapng 文件。
• 模拟器与电脑之间的某个通信网口或虚拟网卡，信令通过 IP 网络封装后落地。
• 第三方协议转换工具或日志工具，把模拟器输出的二进制消息转成标准协议格式，再交给 Wireshark。

这三种来源对应的操作方式不一样。第一种最简单，只要在模拟器里点“开始记录”就行；第二种要选对网卡；第三种要额外关注端口和协议映射。

1.2 先确定你要看的是哪一层，再决定怎么抓

基站模拟器相关测试里，最常被 Wireshark 拿来分析的消息不是 IP 业务数据，而是终端和基站之间的控制面信令。

不同测试阶段关心的协议不完全一样：

这里的 RRC、NAS 这些词如果听着陌生，可以先记一个结论：RRC 主要负责基站和终端之间的无线资源控制，NAS 主要负责终端和核心网之间的注册、鉴权、会话管理。在 Wireshark 里看到这两类消息时，就已经说明模拟器把信令暴露出来了。

1.3 这一篇的演示边界

这篇演示不会去解释模拟器内部每一张配置表怎么填。因为不同型号、不同软件版本的界面差别很大，照着一张截图去点按钮，换个版本就不管用。更好的做法是把思路固定下来：

1. 启动模拟器并完成基本小区配置。
2. 找到信令输出或 PCAP 抓包入口。
3. 用 Wireshark 捕获或打开导出的文件。
4. 用过滤器把协议消息挑出来。
5. 按信令流程判断结果。

这个思路通用，也更容易迁移到其他测试平台上。

2. 演示前的环境准备，避免抓了半天全是空包

2.1 最小环境清单

我建议每次做协议分析演示前，按下面这个清单把环境过一遍，缺一项都可能白忙：

这里最容易理解误区的是“终端”。基站模拟器测试里经常有一个内置测试终端，也可能通过软件模拟终端。第三篇主要讲协议分析，所以不管终端是实体还是软件，只要它能主动发起接入流程就可以。

2.2 三个最容易踩坑的点

第一个坑是抓包驱动没装好。Windows 系统下，如果 Wireshark 安装时没有选择安装 Npcap，后面打开抓包会提示“No interfaces found”或者抓不到任何包。重新安装一次 Npcap 通常能解决，不需要重装 Wireshark。

第二个坑是选错了抓包接口。电脑上往往有好几个网卡，有线的、无线的、虚拟机的、还有模拟器软件创建的虚拟网卡。你选了一个没有任何流量的接口，界面看起来很正常，但抓不到需要的消息。所以开抓之前，先看模拟器控制软件里给出来的抓包地址和接口名，再回去选对应接口。

第三个坑是模拟器本身没把信令输出打开。很多设备默认不会把所有内部消息单独导出，你要在控制台找到“信令跟踪”“PCAP 输出”“Wireshark 联动”这类入口并打开。没有输出动作，电脑端抓包工具再强也拿不到数据。

2.3 先做一次 30 秒的小样本验证

正式测试前，不要直接开批量业务场景。我一般会先跑一次小样本，流程如下：

1. 打开 Wireshark，选择预期接口，点击开始捕获。
2. 在模拟器侧执行一次终端注册，或者让终端重新发起一次接入。
3. 等待 30 秒左右后停止抓包。
4. 先看总包数，再按 IP 或协议过滤，确认里面确实有信令消息。
5. 确认没问题后再清理缓冲区，做正式的长抓包或批量流程。

这样做的原因是：能快速区分是“抓不到”还是“没数据”。如果 30 秒里抓到了几个信令消息，说明链路是通的。如果零包，那就不要继续调整抓包参数，先检查接口和模拟器输出。

3. 从模拟器信令输出到 Wireshark 抓包窗口的完整操作

3.1 找到信令输出入口

德思特基站模拟器控制软件的具体界面需要以你手头的型号为准，但通常有几个可寻的入口。你可以按下面的顺序找：

• 主界面是否直接有“PCAP”“抓包”“协议分析”“WireShark”相关按钮。
• 日志或诊断菜单里是否有“消息记录”“信令跟踪”。
• 设置菜单里是否有“外部抓包服务”“远端日志端口”。

我实测时更建议直接看模拟器的操作手册里“信令跟踪”或“Protocol Analyzer”那一章。别在界面上凭感觉乱点。很多控制软件内部已经集成了一套日志系统，只有把日志输出打开，Wireshark 才能实时看到消息。

如果你的型号支持实时输出，一般会有类似“Start Capture”“Record to PCAP”的按钮。点开后它可能会：

• 自动启动电脑上的 Wireshark；
• 在指定端口监听外部抓包请求；
• 直接在你指定的目录落一个 pcap 文件；
• 或者需要你手动去 Wireshark 里选择一个虚拟接口。

无论哪种方式，只要你能拿到一份包含信令的 pcap 文件或者看到实时抓包的报文，就说明链路已经通了。

3.2 单次抓包的标准顺序

这是我在测试中固定使用的一套操作顺序，适用于大多数场景：

1. 启动基站模拟器，确认小区已经广播，终端处于空闲状态。
2. 打开模拟器信令输出功能，选择 pcap 文件保存路径。
3. 打开 Wireshark，在 Capture Options 里选择对应接口。
4. 先不要发起任何终端动作，开始抓包。
5. 抓包开始后，让终端执行开机、注册、拨号或重新附着动作。
6. 等流程结束后停止抓包。
7. 保存为类似attach_demo.pcapng的文件。

这里的关键点在于：一定要在终端发起动作之前就开始抓包。如果你等终端已经注册成功后再开抓包，那么最开始的 RRC 建立请求已经过去了，后面只能看到部分流程，排查时会少一段最关键的上下文。

如果你更习惯命令行，也可以直接用 tshark 完成相同动作：

# 先列出可用接口编号 tshark -D # 在指定接口上抓包，并保存到文件 tshark -i 5 -w attach_demo.pcapng

抓包过程中终端发起动作，流程结束后按 Ctrl+C 结束 tshark，就能得到一份 pcapng 文件。然后再用 Wireshark 打开分析。

命令行方式的好处是方便批量、可以写脚本，坏处是 Wireshark 图形界面里的显示过滤器不能实时使用，分析时还要再回到图形工具里做。

3.3 抓完之后怎么判断这份包能不能用

打开保存好的 pcapng 文件后，不要急着看具体信令内容。先看几个侧面指标：

• 文件里总包数大于 0，且不是只有 ARP、广播包。
• Protocol 列里有 RRC、NAS、GTP、SCTP、HTTP、TCP 等你能识别出的协议。
• 时间列是连续的，没有长时间空白。
• 模拟器侧显示终端已经注册成功或进入指定状态。
• Wireshark 底部状态栏没有大量 “Malformed Packet” 警告。

如果这些条件都满足，说明这份抓包文件可以作为分析依据。如果只满足前两条，但模拟器侧流程失败，那恰恰是要分析的对象。

4. Wireshark 的过滤和解码功能，先练熟这四个操作

4.1 显示过滤器：用 IP 先圈定范围

抓包文件里经常会混着大量广播、DNS、TCP 重传等消息。如果模拟器信令输出通过某个固定 IP 传输，最直接的办法就是用 IP 过滤来缩小范围。

在 Wireshark 顶部过滤栏输入：

ip.addr == 192.168.1.10

这里的 192.168.1.10 需要替换成你的模拟器信令输出地址。如果抓的是本地回环接口，地址可能就是 127.0.0.1。如果信令经过一段远程抓包服务，你还要结合源端口、目的端口一起过滤。

需要提醒的是：ip.addr 过滤会包含所有发往这个 IP 或从这个 IP 发出来的包。如果你只想看某个方向的流量，可以用 ip.src 和 ip.dst 区分。

ip.src == 192.168.1.10 ip.dst == 192.168.1.10

先按 IP 过滤，能快速把无关广播去掉。然后再在此基础上加协议名，进一步缩小范围。

4.2 不背协议名，用 Packet Details 里的右键菜单生成过滤条件

很多初学者喜欢背 Wireshark 协议过滤条件，比如 rrc、nas-eps、sctp、ngap。这些能不能用，取决于你的 Wireshark 版本和所抓报文的解析结果，不一定背下来就有效。

我更推荐的方法是：在报文列表里找到一条你关心的消息，双击打开 Packet Details 面板，点中某一个协议层，然后右键选择 “Apply as Filter” 或 “Prepare as Filter”。Wireshark 会自动生成正确的显示过滤器语法。

比如你在某条报文的详情树里看到 SIM 卡相关的 NAS 消息，点中那层后右键选择 Apply as Filter，过滤条件会自动变成该层对应的字段。这样做的好处是不容易写错。

4.3 用“Follow”功能串联一次完整交互

有时候一个注册流程会跨越十几条、几十条报文，想在列表里一条条翻很累。这时可以找到一条信令消息，右键选择 “Follow” → “TCP Stream” 或 “UDP Stream”。如果消息走的是 SCTP 或 DCCP，对应关系可能不同，但思路一样：把同一条连接或同一个会话里的所有消息拉出来看。

实际操作里，我一般先找到流程的起始消息，然后 Follow 看这个会话从头到尾的交互顺序。对于排查“发出去一条请求后没有回复”这类问题，Follow 比手动滚动要直观得多。

4.4 用 Protocol Hierarchy 看协议分布

抓包文件如果比较大，可以先看整体协议分布。菜单路径是 “Statistics” → “Protocol Hierarchy”。这个面板会按协议层级展示每种协议占总包数的比例。

如果发现有大量 TCP 重传，说明链路层可能存在丢包或乱序，先别急着分析业务信令，把底层的网络问题解决再说。如果协议分布里完全没有你想看的 RRC、NAS 或相应协议，说明大概率不是过滤问题，而是 Wireshark 没有正确识别报文格式。

5. 结合一次终端注册演示，看信令流程是否正常

5.1 注册成功时应该看到什么

假设我们做的是一次比较常见的入网注册演示。当模拟器已开启小区、终端开机后，通常会在 Wireshark 中看到类似这样的一组信令过程：

1. 终端发起连接请求，目标是建立信令连接。
2. 模拟器回复连接建立消息，配置后续使用的无线资源。
3. 终端回复连接建立完成，同时捎带上注册请求。
4. 模拟器向核心网侧发起认证和注册流程。
5. 终端收到安全相关配置。
6. 核心网接受注册，建立默认承载。
7. 模拟器向终端发送注册接受或附着接受。
8. 信令连接后续被释放，或进入保持状态。

不同协议制式和不同核心网实现的细节会有差异，但整体顺序大致类似。实际分析时不要只看最后有没有成功，还要确认中间步骤确实完整。如果某一步缺失，比如已经发了连接建立完成，却没有后续注册消息，那问题很可能出在终端和核心网参数上。

5.2 终端在模拟器显示注册成功，但 Wireshark 里没有完整流程

这种情况我踩过几次，重点是先检查抓包起点。如果终端早就完成了注册，你中途才开始抓包，当然看不到起始流程。正确做法是先把终端置于飞行模式，再关掉飞行模式，让终端重新发起一次完整注册。

如果重新注册后仍然看不到完整流程，优先确认模拟器信令输出是否覆盖了等待注册前那段空闲过程。有些设备的抓包入口只在业务状态开启后才记录，导致 RRC 建立那几步没有暴露出来。

这时候可以换个验证方式：在模拟器控制界面查看信令日志，看它记录的步骤数和 Wireshark 里的消息数是否能对上。能对上说明 Wireshark 抓全了，只是过滤条件不完整；对不上说明模拟器的信令输出去掉了某一段。

5.3 当 NAS 注册被拒绝时，先记下发消息里的 cause code

注册失败往往会明确拒绝原因。在 Wireshark 消息里找到类似 Registration Reject、Attach Reject、Authentication Reject 这类消息，展开详情可以看到 reject cause 或者一个表示原因的信元。

排查时不急着改参数，先把 cause code 抄下来。这个码是终端和核心网协议栈之间最直接的原因描述。同一个码在不同场景下含义可能不同，需要对照模拟器软件提供的解读表，或者你使用的终端协议栈厂家文档。没有这个码，单纯靠猜参数配置很容易浪费时间。

你也可以故意制造一次错误来做对照。比如把终端里的测试号码或者签约参数改错，再重新附着，观察 Wireshark 里的变化。你会发现 RRC 建立可能还是成功的，但 NAS 层会立刻被拒绝。这样就能直观理解：空口连接正常并不等于注册成功，问题可能在上层参数。

5.4 消息被加密看不到明文怎么办

真实网络里很多 NAS 消息经过完整性保护或加密后，Wireshark 只能看到密文，无法解读信元。基站模拟器测试通常可以不加密，或者使用测试密钥，来方便协议分析。

如果遇到 Wireshark 里消息很长但内容全是不可读数据，先别急着判定模拟器有问题。检查模拟器的安全配置项，看是否关闭了加密和完整性保护，或者是否导入了测试密钥。只要控制侧允许默认不加密，重新发起一次注册流程，通常就能看到明文信元。

这一点也是基站模拟器比真实基站更容易做协议分析的原因：你可以通过配置把黑盒过程换成可读过程。

6. 常见问题排查顺序和实操建议

6.1 抓不到包、空包、只有广播包

按这个顺序排查：

1. 确认 Wireshark 安装时 Npcap 驱动正常。
2. 确认选中了正确的抓包接口。
3. 确认模拟器信令输出功能已经打开。
4. 确认终端真的发起了动作，而不是一直处于空闲态。
5. 确认防火墙没有拦截 Wireshark 接收。Windows 防火墙在某些情况下会弹窗询问，如果点了阻止，后面可能无法监听本机回环或特定端口。
6. 最后再尝试用 pcap 文件离线导入，排除实时抓包链路的问题。

6.2 包抓到了，但显示为原始 TCP 或 UDP，没有协议解析

这种情况很常见，不是没有信令，而是 Wireshark 不知道某个端口对应什么协议。解决方法是右键报文，选择 “Decode As”，然后在规则里指定协议。

比如模拟器把协议数据放在 UDP 的某个自定义端口上，Wireshark 默认只能识别成 UDP。你需要在 Decode As 里把该端口的协议手动指定为对应协议。指定后，报文会立刻重新解析，过滤条件也会按新协议生效。

这里不要背端口号。不同模拟器版本用的端口可能不同，只要你看到原始 TCP/UDP 数据，并且模拟器文档告诉你这是信令端口，就找 Decode As 入口。

6.3 能抓到信令，但信令流程和模拟器日志对不上

先统一时间基准。抓包文件里的时间戳来自电脑系统时间，而模拟器里的日志时间可能来自设备内部时钟。如果两边时间不同步，很难把同一步流程对起来。

我的做法是：

• 抓包开始前，先把电脑系统和模拟器时间同步到同一参考源。
• 在 Wireshark 首选项里把时间显示格式调成 UTC，避免本地时区干扰。
• 抓包保存后用View → Time Display Format → Seconds Since Beginning of Capture看相对时间，判断每步之间的间隔。
• 如果模拟器里能看到时间戳，优先看相对时间而不是绝对时间。

如果时间都对不上但包确实存在，再去检查模拟器信令输出是否有过滤或裁剪。有些控制台默认只输出部分关键提示，并不等于完整信令流。

6.4 一些长期实用的边界建议

这篇教程演示的操作不一定能覆盖德思特基站模拟器所有型号的界面细节。不同型号支持的抓包入口、数据格式、协议范围都可能不同，所以我建议你实际落地时先确认三份材料：

• 模拟器型号对应的操作手册；
• 控制软件中抓包或日志模块的版本说明；
• Wireshark 版本是否满足解码要求。

Wireshark 版本不是越新越好。如果你们测试流程里需要解析特殊私有消息，或者要和模拟器输出的特定 pcap 格式对接，稳定的版本可能比最新版本更合适。抓到关键包后，建议把 Wireshark 版本信息也记录到测试报告里。

最后再说一个经验：不要一上来就跑长时间大流量抓包。小样本验证信令链路，再用 30 秒到 1 分钟跑完一次完整注册流程，确认文件可解析，最后才做长时间观察和批量测试。协议分析的本质不是记录的报文越多越好，而是每一步过程都能被可靠解释。