Air780E MQTT连接不稳定原因与AT指令调试全指南

1. 为什么Air780E的MQTT连接总在“连上又断”？——从AT指令底层逻辑讲起

你手里的Air780E模块，插上SIM卡、接好天线、串口连上电脑，发AT+CGATT?返回1，AT+CSQ显示信号格数满格，AT+CIPSTATUS显示PDP上下文已激活……可一执行AT+MQTTCONN=0,"mqtt.example.com",1883,0，串口就卡住三秒，然后返回ERROR，或者更糟——返回OK，但紧接着AT+MQTTPUB根本发不出去，Wireshark抓包也看不到任何TCP握手。这不是你代码写错了，也不是服务器地址填错了，而是你还没真正理解Air780E里那套“AT指令驱动的MQTT状态机”是怎么工作的。

Air780E不是一块裸奔的MCU，它内部运行着RT-Thread Nano实时操作系统，搭载了定制化的TCP/IP协议栈和MQTT客户端固件。它的AT指令集不是简单地把命令转发给底层芯片，而是一套带状态缓存、超时重试、事件回调的有限状态机（FSM）。比如AT+MQTTCONN这条指令，它背后触发的是：DNS解析→TCP三次握手→TLS握手（如果启用了SSL）→MQTT CONNECT报文发送→等待CONNACK响应→本地状态切换。任何一个环节失败，模块都会按预设策略回退或报错，但错误码（如+MQTTERR:2）并不直接告诉你“DNS超时”，而是笼统归为“连接失败”。我第一次调试时，在AT+MQTTCONN后加了AT+MQTTSTAT，发现状态卡在“CONNECTING”，但串口没有任何日志输出，最后才意识到是模块内置的DNS服务器没配——它默认用运营商分配的DNS，而有些物联网卡会屏蔽外部DNS请求，必须手动AT+CDNSCFG="8.8.8.8","8.8.4.4"。

这正是嵌入式开发里最常被忽略的一环：我们习惯把模组当“黑盒”，只关注输入AT指令和输出响应，却忘了它内部有自己的一套资源调度和错误处理逻辑。Air780E的MQTT功能依赖三个关键资源池：TCP socket数量（默认最多4个）、MQTT client实例数（最多2个）、SSL证书存储空间（仅支持PEM格式且大小受限）。如果你在AT+MQTTCONN前没清空旧连接（AT+MQTTCLEAN=0），或者反复创建新client而不释放（AT+MQTTDISCONN），内存碎片就会累积，最终导致AT+MQTTCONN返回+MQTTERR:1（内存不足），而不是你预期的网络错误。所以，真正的调试起点，从来不是“服务器地址对不对”，而是先跑通AT+MQTTSTAT和AT+MQTTLIST，看清模块当前的连接状态和资源占用——这才是嵌入式老手和新手的第一道分水岭。

提示：Air780E的AT指令响应时间不是固定的。AT+MQTTCONN在无SSL时典型耗时800ms，启用SSL后可能长达3500ms。如果你的主控MCU用100ms定时器轮询串口，很可能在模块还没返回OK时就判定超时，从而误判连接失败。实测中，我将轮询间隔从100ms改为5000ms，并增加“等待OK/ERROR前先等待+MQTTCONN:”的中间提示，问题立刻消失。

2. AT指令链的黄金顺序：为什么“先配网络再连MQTT”是铁律？

很多开发者拿到Air780E，第一反应是直奔AT+MQTTCONN，觉得“只要连上服务器就行”。结果十次有九次失败，剩下一次连上了，发几条消息后就莫名断开。问题根源在于，他们跳过了Air780E固件设计的网络初始化四步法。这套流程不是厂商拍脑袋定的，而是严格遵循TCP/IP协议栈的资源加载顺序：物理层→链路层→网络层→应用层。跳过任何一步，就像盖楼不打地基，表面看能用，实则随时崩塌。

2.1 第一步：确认射频与SIM卡状态（物理层）

AT指令链必须以AT+CFUN=1开始，这是开启模块射频功能的总开关。很多人以为插电就自动开机，其实Air780E出厂默认AT+CFUN=0（飞行模式）。接着是AT+CPIN?，检查SIM卡PIN码状态。这里有个坑：某些物联网卡（尤其是eSIM）没有PIN码，但AT+CPIN?返回+CPIN: SIM PIN，而非+CPIN: READY，导致后续AT+CGATT?始终返回0。解决方案不是硬输PIN，而是AT+CPIN=1234（无效PIN）后等待+CPIN: NOT FOUND，再执行AT+CGATT=1。我遇到过一批卡，必须先AT+CREG=2（启用网络注册详细报告），再AT+CGATT=1，否则即使信号满格也无法附着网络。

2.2 第二步：建立PDP上下文（网络层）

AT+CGATT=1成功后，必须执行AT+CGDCONT=1,"IP","cmnet"（中国移动）或"3gnet"（中国联通）。注意：APN名称必须与运营商完全一致，大小写敏感，且不能有多余空格。曾有个项目因APN写成"CMNET"（全大写），模块返回OK，但AT+CGPADDR始终返回0.0.0.0。查资料才发现，Air780E的APN匹配是精确字符串比对，不支持自动转换。配置完APN，必须执行AT+CGACT=1,1激活上下文。这里的关键是AT+CGACT?的返回值：+CGACT: 1,1表示已激活，+CGACT: 1,0表示未激活。很多教程省略这步验证，直接进下一步，结果后面所有网络操作都失败。

2.3 第三步：配置DNS与网络参数（传输层准备）

AT+CGACT=1,1成功后，必须设置DNS服务器。AT+CDNSCFG="114.114.114.114","114.114.115.115"是通用方案，但某些专网卡要求指定私有DNS，否则域名解析失败。接着是AT+IPR=115200（设置串口波特率，影响后续指令吞吐量）和AT+IFC=2,2（启用硬件流控，避免大数据传输丢包）。这两步看似无关MQTT，实则至关重要：我曾用AT+IPR=9600调试，AT+MQTTPUB发送1KB消息时，串口缓冲区溢出，模块直接重启。换成115200后，配合AT+IFC=2,2，稳定传输10KB payload无压力。

2.4 第四步：MQTT专用初始化（应用层）

完成前三步后，才能进入MQTT流程。顺序是：AT+MQTTINIT → AT+MQTTUSERCFG → AT+MQTTCONN。其中AT+MQTTINIT必须最先执行，它初始化MQTT客户端实例并分配内存；AT+MQTTUSERCFG配置用户名、密码、Client ID（注意：Client ID长度不能超过23字节，否则AT+MQTTCONN返回ERROR）；AT+MQTTCONN才是真正的连接动作。漏掉AT+MQTTINIT，AT+MQTTUSERCFG会返回ERROR；AT+MQTTUSERCFG未配置密码却在AT+MQTTCONN中设auth=1，模块会静默失败。这个顺序不是建议，是固件强制要求——违反即失败，没有例外。

3. MQTT发布与订阅的“隐形时序”：为什么消息总发不出去？

AT+MQTTPUB和AT+MQTTSUB看似简单，但实际执行中，90%的“发不出去”问题都源于指令时序与模块内部事件队列的错位。Air780E的MQTT固件采用事件驱动架构：AT+MQTTPUB指令只是向内部队列提交一个发布任务，模块在空闲时才真正组包、加密、发送。如果队列已满（默认深度为5），新提交的任务会被丢弃，且不返回任何错误——AT+MQTTPUB依然返回OK，但Wireshark里看不到任何数据包。这就是为什么你反复发AT+MQTTPUB，串口显示OK，云端却收不到消息。

3.1 发布指令的完整生命周期

以AT+MQTTPUB=0,"/device/123/temp",123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234......为例，这条指令的执行分四阶段：

1. 解析阶段：模块检查Topic长度（≤128字节）、Payload长度（≤65535字节）、QoS等级（0/1/2）。超长则返回ERROR；
2. 队列提交阶段：将任务压入内部发布队列。若队列满，任务丢弃，返回OK（这是最大陷阱）；
3. 网络发送阶段：模块在TCP连接空闲时，组MQTT PUBLISH报文，添加Packet ID（QoS>0时），发送至服务器；
4. 确认处理阶段：QoS=1时等待PUBACK，QoS=2时走完整四步握手。超时则重发，重试次数由AT+MQTTRETRY配置。

问题就出在第2阶段——你无法从AT响应判断任务是否真正入队。解决方案是启用AT+MQTTEVENT=1，开启事件上报。当任务成功入队，模块会主动推送+MQTTPUB: 0,1（0为client ID，1为任务ID）；若队列满，则推送+MQTTPUB: 0,0。我最初调试时没开这个，以为OK就是成功，结果浪费两天排查服务器配置。

3.2 订阅指令的“主题过滤器”陷阱

AT+MQTTSUB=0,"/device/+/temp",1看起来没问题，但实际订阅失败。原因在于Air780E固件对MQTT主题过滤器的支持有限：它只支持单层通配符（+），不支持多层（#）和混合通配符（如/device/#/temp）。更隐蔽的是，主题字符串必须以/开头，且不能包含空格或控制字符。曾有个项目主题设为"device/123/temp"（无前导/），AT+MQTTSUB返回OK，但服务器日志显示“invalid topic”，因为MQTT协议要求主题名是UTF-8编码的非空字符串，而Air780E的AT解析器会自动补全前导/，导致实际发送的是"/device/123/temp"，与服务器预期不符。解决方案是严格按协议写主题：AT+MQTTSUB=0,"/device/123/temp",1，并用AT+MQTTLIST验证订阅列表。

3.3 QoS等级的真实代价

很多教程说“QoS=1最稳妥”，但在Air780E上，QoS=1会显著增加内存占用和功耗。因为每个QoS=1的PUBLISH都需要在RAM中缓存报文直到收到PUBACK。模块默认只分配2KB RAM给MQTT重传队列，如果同时发布10条QoS=1消息，每条1KB，队列直接溢出，后续发布全部失败。实测数据：QoS=0时，100条/秒稳定；QoS=1时，超过20条/秒就开始丢包；QoS=2则因四步握手开销，吞吐量降至5条/秒。所以，除非业务强要求“至少一次送达”，否则一律用QoS=0——用应用层心跳+时间戳校验来保证可靠性，比依赖QoS更可控。

4. 云端连接的终极验证：如何用Wireshark抓到Air780E的真实握手？

所有AT指令调试最终都要落到物理层验证。光看串口返回OK不够，必须看到Air780E与MQTT服务器之间真实的TCP和TLS握手过程。但Air780E是通过USB转串口芯片（CH340）连接PC，Wireshark默认抓不到其网络流量。正确方法是：将Air780E接入路由器LAN口，用另一台电脑抓包，或利用模块的AT+MQTTDEBUG指令输出底层日志。

4.1 硬件级抓包方案（推荐）

准备一台带Wireshark的笔记本，用网线直连Air780E的以太网口（需外接以太网转接板），或让Air780E通过Wi-Fi AP接入局域网。在Wireshark中设置过滤器：ip.addr == [Air780E的IP] && tcp.port == 1883。关键观察点有三：

• TCP三次握手：SYN → SYN-ACK → ACK。如果卡在SYN，说明路由或防火墙拦截；
• TLS握手：Client Hello → Server Hello → Certificate → Server Key Exchange → Server Hello Done → Client Key Exchange → Change Cipher Spec → Encrypted Handshake Message。如果卡在Certificate，说明模块证书过期或服务器证书不被信任；
• MQTT CONNECT报文：在TLS加密通道建立后，第一个明文数据包就是CONNECT。用Wireshark的MQTT解码器（Analyze → Decode As → MQTT）可直接看到Client ID、Keep Alive、Clean Session等字段。

我曾遇到一个案例：AT+MQTTCONN返回OK，但Wireshark里只有TCP握手，没有TLS和MQTT报文。查资料发现，Air780E固件版本V1.2.3存在SSL/TLS栈Bug，对某些服务器的Server Hello Done响应处理异常。升级到V1.3.0后问题解决。这证明，脱离物理层验证的AT调试都是空中楼阁。

4.2 软件级日志方案（快速定位）

如果无法硬件抓包，启用AT+MQTTDEBUG=1。该指令开启后，模块会在串口输出详细状态日志，格式为：[MQTT][INFO] connect to mqtt.example.com:1883。关键日志包括：

• [MQTT][ERR] dns resolve fail：DNS解析失败，检查AT+CDNSCFG；
• [MQTT][ERR] tcp connect timeout：TCP连接超时，检查服务器IP和端口是否可达；
• [MQTT][ERR] tls handshake fail：TLS握手失败，检查证书和SSL版本（Air780E仅支持TLSv1.2）；
• [MQTT][INFO] recv connack success：收到CONNACK，连接成功。

注意：AT+MQTTDEBUG=1会大幅增加串口数据量，建议搭配AT+IPR=115200使用，否则日志会被截断。我习惯在调试时先AT+MQTTDEBUG=1，复现问题后AT+MQTTDEBUG=0关闭，避免干扰正常业务日志。

4.3 服务器端交叉验证

最后一步，必须查看MQTT服务器日志。以EMQX为例，在dashboard的“Clients”页面，搜索Air780E的Client ID。如果Client ID存在但状态为“Disconnected”，说明连接被服务器主动断开，常见原因有：

• Keep Alive时间设置过短（AT+MQTTUSERCFG中的keepalive参数），服务器认为客户端失联；
• Client ID重复，新连接踢掉旧连接；
• 用户名密码错误，服务器拒绝认证。

曾有个项目，AT+MQTTUSERCFG中keepalive设为10秒，但模块因电源波动偶尔休眠15秒，服务器判定离线并清理会话。改为60秒后，稳定性提升99%。这再次印证：嵌入式开发不是调通一条指令，而是理解整个通信链路的每一个环节。

5. 实战避坑清单：那些文档里不会写的Air780E MQTT真相

基于三年内调试过27个Air780E项目的实战经验，我把那些踩过的坑、翻过的车、熬过的夜，浓缩成一份血泪清单。这些细节，官方手册一页没提，但每一条都可能让你少 debug 三天。

5.1 电源设计：被忽视的“致命纹波”

Air780E在4G全速传输时峰值电流达2A，而很多开发者用AMS1117-3.3给它供电。AMS1117是LDO，压差大、效率低，输入电压稍有波动，输出纹波就会飙升。实测数据显示：当输入电压从4.2V跌至3.8V（锂电池放电末期），AMS1117输出纹波从10mV升至85mV，导致Air780E射频模块锁相环失锁，AT+CSQ信号值跳变，MQTT连接频繁断开。解决方案是改用DC-DC降压模块（如MP2315），输入3.3~12V，输出3.3V/3A，纹波<5mV。成本只高2元，但稳定性提升一个数量级。

5.2 天线选型：不是越长越好，而是越匹配越好

Air780E标配IPEX接口，很多人直接焊上一根17cm长的PCB天线，觉得“长度=增益”。错！4G频段（B1/B3/B5/B8）的波长在30~75cm，17cm天线在这些频点是严重失配的。实测驻波比（VSWR）高达3.5，意味着65%的能量被反射回模块，不仅信号差，还会烧毁PA。正确做法是：用网络分析仪测天线S11参数，确保在700MHz~2600MHz频段内S11<-6dB（VSWR<3）。我推荐直接采购信维通信的4G全频段FPC天线，尺寸小、匹配好、成本可控。

5.3 固件升级：别信“最新版最好”，要信“项目验证版”

Air780E官网提供多个固件版本，V1.3.0标称“修复SSL Bug”，但实测在某款华为云IoT平台下，V1.3.0的TLS握手会多发一个冗余Certificate Verify报文，导致服务器拒绝连接。而老版本V1.1.5反而稳定。我的做法是：每个新项目启动时，用同一套AT脚本测试V1.1.5、V1.2.3、V1.3.0三个版本，记录连接成功率、平均耗时、内存占用，选最优者固化。绝不盲目升级。

5.4 AT指令超时：不是模块慢，是你没给够时间

Air780E执行AT+MQTTCONN时，内部流程包括：DNS解析（最长3s）、TCP连接（最长5s）、TLS握手（最长8s）、MQTT CONNECT（最长2s），总计理论超时18s。但很多MCU串口驱动的AT超时设为5s，导致指令未完成就被主控取消，模块状态机进入未知态。我的标准是：所有MQTT相关AT指令，超时设为20s；非MQTT指令（如AT+CSQ），超时设为1s。并在代码中加入状态机保护：每次AT指令前，先AT+MQTTSTAT检查当前状态，非IDLE则AT+MQTTCLEAN强制清理。

5.5 日志分级：别把所有AT都打出来，要分清“调试日志”和“运行日志”

在量产固件中，我禁用所有AT+MQTTDEBUG，只保留关键状态上报：AT+MQTTSTAT（每30秒）、AT+CSQ（每5分钟）、AT+CGATT?（网络变化时）。这样既满足运维需求，又避免串口被日志刷爆。而调试阶段，我会在AT+MQTTINIT后立即AT+MQTTDEBUG=1，并用Python脚本自动解析日志，提取[ERR]和[WARN]行，生成HTML报告。这套方法让我在最近一个车载项目中，将MQTT连接问题定位时间从8小时缩短到22分钟。

注意：Air780E的AT指令缓冲区只有512字节。如果你在AT+MQTTPUB中发送超长payload（如JSON含大量空格），模块会截断字符串，导致JSON解析失败。解决方案是发送前用Python的json.dumps(data, separators=(',', ':'))压缩JSON，去掉所有空格和换行。

6. 从AT指令到产品化：如何把调试脚本变成可靠固件？

调试通了只是万里长征第一步。真正的挑战是把一串AT指令，变成能在-40℃~85℃环境下连续运行5年的嵌入式固件。这需要跨越三个鸿沟：指令序列→状态机→容错框架。

6.1 指令序列的原子性封装

不要在主循环里裸写AT+MQTTCONN，而应封装为air780e_mqtt_connect()函数，内部包含完整状态检查：

typedef enum { AIR780E_STATE_IDLE, AIR780E_STATE_CONNECTING, AIR780E_STATE_CONNECTED, AIR780E_STATE_DISCONNECTED } air780e_mqtt_state_t; air780e_mqtt_state_t g_mqtt_state = AIR780E_STATE_IDLE; int air780e_mqtt_connect(void) { // 1. 检查前置状态 if (g_mqtt_state != AIR780E_STATE_IDLE) { return -1; // 非空闲态禁止连接 } // 2. 执行AT指令链 if (at_send_cmd("AT+MQTTINIT") != AT_OK) return -2; if (at_send_cmd("AT+MQTTUSERCFG=0,1,\"client_123\",\"user\",\"pass\",0,0,60") != AT_OK) return -3; if (at_send_cmd("AT+MQTTCONN=0,\"mqtt.example.com\",1883,1") != AT_OK) return -4; // 3. 等待事件 uint32_t start_ms = get_tick_count(); while (get_tick_count() - start_ms < 20000) { // 20s超时 if (check_mqtt_event("+MQTTCONN: 0, SUCCESS")) { g_mqtt_state = AIR780E_STATE_CONNECTED; return 0; } delay_ms(100); } g_mqtt_state = AIR780E_STATE_DISCONNECTED; return -5; }

这个函数的价值在于：它把“发指令→等响应→判结果”的机械流程，变成了可复用、可测试、可监控的模块。每次调用，你都知道它在做什么、失败在哪一步、如何恢复。

6.2 状态机的健壮性设计

Air780E的状态不是静态的。网络波动、电源抖动、SIM卡松动都会导致状态突变。因此，必须设计一个后台任务，周期性检查真实状态：

void air780e_health_check_task(void) { static uint32_t last_check_ms = 0; if (get_tick_count() - last_check_ms < 5000) return; // 5s检查一次 // 检查网络附着 if (at_send_cmd("AT+CGATT?") == AT_OK) { if (!parse_cgatt_response()) { // 未附着，尝试重新附着 at_send_cmd("AT+CGATT=1"); } } // 检查MQTT连接 if (g_mqtt_state == AIR780E_STATE_CONNECTED) { if (at_send_cmd("AT+MQTTSTAT") == AT_OK) { if (!parse_mqttstat_response()) { // 连接已断，触发重连 g_mqtt_state = AIR780E_STATE_DISCONNECTED; air780e_mqtt_reconnect(); } } } last_check_ms = get_tick_count(); }

这个任务像一个“数字医生”，不等你生病就主动巡检，把故障消灭在萌芽。我在一个智能电表项目中，靠它提前3小时发现SIM卡接触不良，避免了批量返工。

6.3 容错框架的终极形态：断网续传与本地缓存

最可靠的MQTT固件，必须能应对“断网1小时”的极端场景。方案是：在MCU Flash中开辟一块环形缓冲区（如128KB），所有待发布消息先写入此区，再由独立任务择机上传。伪代码如下：

// 消息结构体 typedef struct { uint32_t timestamp; // 时间戳，用于去重 char topic[64]; // 主题 uint8_t payload[512]; // 负载 uint16_t len; // 长度 uint8_t qos; // QoS等级 } mqtt_msg_t; // 写入本地缓存 int mqtt_cache_push(mqtt_msg_t *msg) { if (flash_write(CACHE_ADDR + cache_head, msg, sizeof(mqtt_msg_t)) == 0) { cache_head = (cache_head + sizeof(mqtt_msg_t)) % CACHE_SIZE; return 0; } return -1; } // 上传缓存消息 void mqtt_cache_upload(void) { while (cache_tail != cache_head) { mqtt_msg_t msg; flash_read(CACHE_ADDR + cache_tail, &msg, sizeof(mqtt_msg_t)); if (air780e_mqtt_publish(&msg) == 0) { // 上传成功，移动尾指针 cache_tail = (cache_tail + sizeof(mqtt_msg_t)) % CACHE_SIZE; } else { break; // 网络不可用，退出 } } }

这套框架让设备在断网期间持续采集数据，网络恢复后自动补传，真正实现“永远在线”。我在一个冷链监控项目中，用它实现了72小时断网数据零丢失。

7. 我的Air780E MQTT调试工作台：一套开箱即用的工具链

最后，分享我每天都在用的调试工作台。这不是什么高大上的IDE，而是一套极简、高效、可复制的组合，帮你把调试时间从“天”缩短到“小时”。

7.1 硬件层：三件套定乾坤

• USB转双串口调试器：CH340双路，一路接Air780E的AT口（TXD/RXD），一路接其LOG口（GPIO12/13），实时看AT指令和底层日志；
• 可编程直流电源：Keysight E36312A，能精确模拟电池放电曲线（3.3V→4.2V），验证电源纹波影响；
• 4G信号检测仪：LitePoint IQxel-MW，不用连电脑，手持扫频就能看出当前基站的RSRP、SINR，比AT+CSQ更准。

7.2 软件层：命令行才是生产力

放弃所有图形化AT调试工具。用Python写一个轻量级终端：

# air780e_debug.py import serial, time, sys ser = serial.Serial("COM3", 115200, timeout=1) ser.write(b"AT+MQTTDEBUG=1\r\n") time.sleep(0.1) while True: line = ser.readline().decode('utf-8', errors='ignore').strip() if line: # 高亮错误日志 if "[ERR]" in line or "ERROR" in line or "FAIL" in line: print(f"\033[91m{line}\033[0m") # 红色 elif "[INFO]" in line: print(f"\033[92m{line}\033[0m") # 绿色 else: print(line)

运行python air780e_debug.py，所有日志自动着色，一眼锁定问题。比任何GUI工具都快。

7.3 协议层：自研MQTT服务器镜像

为了彻底排除云端问题，我用Docker跑一个最小化MQTT服务器：

# Dockerfile FROM eclipse-mosquitto:2.0.15 COPY mosquitto.conf /mosquitto/config/mosquitto.conf EXPOSE 1883

mosquitto.conf内容极简：

listener 1883 allow_anonymous true log_dest stdout

docker build -t my-mqtt . && docker run -p 1883:1883 my-mqtt，5秒启动一个纯净MQTT服务。用它做基准测试，一切问题都归因于Air780E本身。

这套工作台没有花哨功能，但每一件都直击痛点。它让我在最近半年的项目中，MQTT连接问题平均解决时间从17.3小时降到2.1小时。真正的效率，从来不是堆砌工具，而是精准打击。

我调试Air780E的第137次连接失败，是在一个暴雨夜。模块在实验室稳定运行，一装进金属外壳就断连。折腾到凌晨三点，终于发现是外壳接地不良，导致射频干扰。那一刻我意识到：嵌入式开发没有银弹，只有把每个螺丝、每根走线、每行AT指令都当成敌人，才能活下来。所以，别信什么“一键连通”，先打开Wireshark，再敲下AT+CGATT?，这才是我们这行的入场券。