? 必須要吐槽一下：最近被老板驅(qū)使，要用Air780EP模塊做幾個(gè)緊急項(xiàng)目。。。

就怕緊急項(xiàng)目，時(shí)間緊任務(wù)重，遇到了一些棘手問(wèn)題，可把我給折騰死了……

這里把遇到的問(wèn)題，排查記錄下來(lái)，看能不能幫到因遇到類似的問(wèn)題，并且一直沒(méi)找到原因，而被老板要求加班解決的兄弟們。

一、相關(guān)背景簡(jiǎn)介

不知道各位在用Cat.1模塊的時(shí)候，會(huì)不會(huì)遇到收不到網(wǎng)絡(luò)數(shù)據(jù)的問(wèn)題呢？

比如：

"用TCP做長(zhǎng)鏈接，在進(jìn)入休眠場(chǎng)景后進(jìn)行?；?，但時(shí)常出現(xiàn)丟包的現(xiàn)象，應(yīng)該怎么分析呢"、"MQTT服務(wù)器下行數(shù)據(jù)，模塊有概率接收不到，服務(wù)器也有遇到收不到模塊的上行數(shù)據(jù)，到底是什么情況"等等類似的問(wèn)題。

但單純通過(guò)模塊這邊看到的現(xiàn)象，也不能斷定就是模塊出了問(wèn)題。

要想準(zhǔn)確地找出這個(gè)“罪犯”，這種時(shí)候就需要通過(guò)網(wǎng)絡(luò)抓包來(lái)分析排查是以下哪種原因：

• 模塊有發(fā)出數(shù)據(jù)->但服務(wù)器沒(méi)收到
• 模塊未發(fā)出數(shù)據(jù)->導(dǎo)致服務(wù)器沒(méi)收到
• 服務(wù)器有發(fā)出數(shù)據(jù)->但模塊沒(méi)收到
• 服務(wù)器未發(fā)出數(shù)據(jù)->導(dǎo)致模塊沒(méi)收到

以下通過(guò)最近遇到的一個(gè)實(shí)例，給各位提供個(gè)分析思路。

目前有個(gè)項(xiàng)目用的是AT開(kāi)發(fā)，大致應(yīng)用場(chǎng)景為TCP長(zhǎng)鏈接，要求定時(shí)上報(bào)GPS/基站/Ｗi-Fi的定位數(shù)據(jù)，沒(méi)有休眠需求。

但時(shí)不時(shí)在發(fā)送數(shù)據(jù)的時(shí)候，會(huì)出現(xiàn)AT+CIPSEND發(fā)數(shù)據(jù)發(fā)著發(fā)著返回**+CME: ERROR 3**的問(wèn)題。

基本情況解析：

• 使用的數(shù)據(jù)傳輸協(xié)議為TCP
• 問(wèn)題現(xiàn)象為偶現(xiàn)，小概率出現(xiàn)
• 從模塊查看到的異常情況為：
  AT+CIPSEND發(fā)送TCP數(shù)據(jù)的指令，出現(xiàn)了+CME: ERROR 3的錯(cuò)誤碼

首先按照+CME: ERROR 3這個(gè)錯(cuò)誤碼出現(xiàn)的條件，篩選一下可能出現(xiàn)的有哪些情況：

• 最先想到的就是TCP鏈接已經(jīng)不存****在，斷開(kāi)了
  導(dǎo)致發(fā)送數(shù)據(jù)時(shí)檢測(cè)TCP通道關(guān)閉，而出現(xiàn)AT+CIPSEND命令返回錯(cuò)誤。
• 發(fā)送的AT+CIPSEND命令前后攜帶了其他的字符
  一起作為一整條指令發(fā)送給了模塊，導(dǎo)致模塊解析出錯(cuò)。

AT+CIPSEND這條指令會(huì)出現(xiàn)+CME: ERROR 3，基本上就是以上兩種情況了。

那么先嘗試排除下第二條：

我在偶現(xiàn)第一次AT+CIPSEND出現(xiàn)錯(cuò)誤之后，后面也嘗試發(fā)送了的多條AT+CIPSEND命令發(fā)現(xiàn)也都會(huì)出錯(cuò)。

但中間穿插發(fā)送的AT+CEREG?、AT+CGATT?、AT+CSQ 查網(wǎng)絡(luò)狀態(tài)、信號(hào)強(qiáng)度的命令返回都正常，也沒(méi)有報(bào)錯(cuò)。

而且把發(fā)送的整條數(shù)據(jù)轉(zhuǎn)為以HEX格式來(lái)看，指令前后也沒(méi)有多余的字符出現(xiàn)。

那可以排除第二種情況了。

接下來(lái)這個(gè)時(shí)候?yàn)榱擞∽C第一條的猜想，

就需要排查下問(wèn)題是否為TCP鏈接已經(jīng)斷開(kāi)了：

在掛測(cè)了一段時(shí)間再次復(fù)現(xiàn)問(wèn)題的時(shí)候，

加一條AT+CIPSTATUS的命令查一下連接狀態(tài)。

結(jié)果不出所料：

返回的結(jié)果是 STATE: TCP CLOSED ，

TCP鏈接是斷開(kāi)的狀態(tài)！

已經(jīng)鎖定問(wèn)題原因是有概率出現(xiàn)TCP突然斷鏈的現(xiàn)象。

由于目前條件抓不了服務(wù)器端的網(wǎng)絡(luò)日志，只能暫且想辦法從模塊端排查問(wèn)題。

出現(xiàn)斷鏈也可以分為：

模塊端發(fā)起斷開(kāi)連接和服務(wù)器端發(fā)起斷開(kāi)連接。

如果為模塊端斷接：

可以看下是否有主動(dòng)發(fā)送AT+CIPCL****OSE去斷開(kāi)連接，但我從AT流程的日志來(lái)看，明顯程序中還沒(méi)有走到AT+CIPCLOSE這一步，問(wèn)題就已經(jīng)復(fù)現(xiàn)了。

模塊端如果沒(méi)有主動(dòng)通過(guò)指令斷開(kāi)連接：

那么在遇到網(wǎng)絡(luò)波動(dòng)、信號(hào)差、卡沒(méi)流量等等，會(huì)影響網(wǎng)絡(luò)的事件時(shí)，模塊也可能會(huì)發(fā)起斷開(kāi)連接的請(qǐng)求。

但上面也已經(jīng)排查過(guò)：

在出現(xiàn)AT+CIPSEND返回ERROR之后，

也發(fā)送了AT+CEREG?、AT+CGATT?、AT+CSQ這三條指令。

返回結(jié)果依次為：

+CEREG: 0,1

+CGATT: 1

+CSQ: 25

可以從CEREG和CGATT的返回結(jié)果看出，網(wǎng)絡(luò)狀態(tài)是正常已成功注冊(cè)網(wǎng)絡(luò)的，CSQ信號(hào)值為25，也很正常。

那這到底是怎么回事呢？

這下不得不通過(guò)網(wǎng)絡(luò)抓包來(lái)進(jìn)一步分析了。

二、準(zhǔn)備工作要點(diǎn)

根據(jù)項(xiàng)目需求準(zhǔn)備相關(guān)硬件及軟件，以下供參考：

• 自制板子需要引出USB或者DBG_UART串口，二選一。
  但如果問(wèn)題是 只有在休眠環(huán)境下才能復(fù)現(xiàn)的，那么只能使用DBG_UART串口， 進(jìn)入休眠后USB要斷開(kāi)會(huì)導(dǎo)致抓不到休眠中的日志。
• 如果使用DBG_UART串口，還需要準(zhǔn)備一個(gè)高速串口工具（能支持6M波特率，例如ch343、ft4232）。
• 合宙開(kāi)發(fā)板默認(rèn)有引出USB和DBG_UART串口，可以直接接線使用。
• EPAT log工具 EPAT_V1.3.262.573，使用方式本文章也會(huì)簡(jiǎn)單說(shuō)明，在EPAT軟件 Manual 目錄中也有一份使用介紹的PDF。
• Wireshark網(wǎng)絡(luò)包分析工具：

三、怎么抓日志

3.1 選擇正確且合適的日志輸出端口

USB的虛擬端口其中有一個(gè)為底層日志的輸出端口。

可從設(shè)備管理器端口屬性中“設(shè)備實(shí)例路徑”的值為：

"USBVID_19D1&PID_0001&MI_04xxxxxx&0&0004"

鎖定到底層日志輸出端口是哪一個(gè)。

?

**建議使用USB來(lái)抓取日志 **

優(yōu)點(diǎn)： USB虛擬端口輸出速率很高，所以基本不會(huì)出現(xiàn)丟日志的現(xiàn)象；

缺點(diǎn)： 連接USB時(shí)不會(huì)進(jìn)入休眠。

DBG_UART串口需要以6M波特率輸出底層日志，此串口輸出的數(shù)據(jù)要通過(guò)EPAT工具才可以解析。

優(yōu)點(diǎn)： 進(jìn)入休眠的日志也同樣可以抓取。

缺點(diǎn)： 但因?yàn)椴ㄌ芈室笤?M，所以對(duì)串口線的要求很高，如果引出的杜邦線太長(zhǎng)或者質(zhì)量不高，也會(huì)影響日志輸出的數(shù)據(jù)，導(dǎo)致工具不能正常解析。

3.2 ****認(rèn)識(shí)EPAT工具中的圖標(biāo)功能

以下從左至右依次介紹：

?

1）重啟模塊；

2）勾選選擇的端口從其他串口調(diào)試工具嘗試打開(kāi)是否可以正常輸出數(shù)據(jù)（正常打開(kāi)輸出的就是亂碼）；

3）如果使用AT固件，默認(rèn)DBG_UART端口輸出是6M波特率。

可以通過(guò)：

AT+ECPCFG=logBaudrate,6000000 指令修改，

波特率設(shè)置請(qǐng)不要低于6M，不然很容易出現(xiàn)丟日志、抓的不全。

• 打開(kāi)日志文件
  需要在打開(kāi)EPAT工具時(shí)跳出的"Select Data Source"選擇框中選擇"Select From Local Files"，才能點(diǎn)擊打開(kāi)日志文件的功能，可以打開(kāi)ZIP壓縮包和Bin格式的日志文件。
• 保存日志
  會(huì)將已抓取到的日志導(dǎo)出，以ZIP壓縮包的方式保存，方便提供給技術(shù)同事或研發(fā)同事分析。
• 更新解析日志的數(shù)據(jù)庫(kù)文件
  在抓日志的時(shí)候，可以不匹配，等在使用EPAT打開(kāi)日志文件的時(shí)候再做匹配解析。
• 篩選查看日志
  如果不了解，用不到這個(gè)功能。
• 啟動(dòng)開(kāi)始抓日志
  如果沒(méi)有日志出來(lái)，請(qǐng)檢查日志端口有沒(méi)有選擇正確，有沒(méi)有勾選打開(kāi)；確認(rèn)端口正確，也以勾選，還是沒(méi)有日志出來(lái)，請(qǐng)嘗試：
• 暫停日志
• 停止抓日志
  點(diǎn)擊完停止后，就可以選擇保存日志，發(fā)給技術(shù)/研發(fā)同事分析了。
• 清除日志
  建議每次正式準(zhǔn)備抓日志前清理一下日志，這樣保存出來(lái)的日志給技術(shù)同事分析會(huì)方便很多。
• 搜索當(dāng)前view視圖的日志內(nèi)容
• 設(shè)備端口配置界面

3.3 底層日志抓取步驟

3.3.1 打開(kāi)EPAT工具，抓日志選擇第一項(xiàng)“Serial Device”

?

3.3.2 選擇日志端口，準(zhǔn)備抓取log

?

接下來(lái)將從選擇使用USB的虛擬日志端口 、選擇使用DBG_UART串口，以及兩個(gè)端口都使用的方式，分別進(jìn)行詳細(xì)講解：

3.3.3 選擇使用USB的虛擬日志端口

**使用USB的虛擬日志端口流程 **

• 打開(kāi)設(shè)備端口配置界面；
• 關(guān)閉或打開(kāi)端口，如果端口被占用，工具也不會(huì)提示"端口已被占用"，所以如果發(fā)現(xiàn)端口選擇正確，并且日志還是沒(méi)有出來(lái)的話，可以確認(rèn)下日志端口是否有被占用，而導(dǎo)致EPAT沒(méi)有打開(kāi)日志端口。
• Device0、Device1兩個(gè)復(fù)選框，二選其一；
• 打開(kāi)日志輸出端口和修改波特率的界面：
  選擇從設(shè)備管理器端口屬性中“設(shè)備實(shí)例路徑”的值為：
  "USBVID_19D1&PID_0001&MI_04xxxxxx&0&0004"的日志輸出端口。
• USB的虛擬日志端口不用修改波特率。

這時(shí)前面流程都走完了，但是發(fā)現(xiàn)沒(méi)有日志出來(lái)。

首先可以確認(rèn)下模塊是否開(kāi)機(jī)：

最直接的方式就是量vbat的電壓是否在4.3v~3.3v之間，并且看VDD_EXT是否有1.8v或3.3v，電壓正常就說(shuō)明模塊是處于開(kāi)機(jī)狀態(tài)了。

其他類似于看網(wǎng)絡(luò)燈沒(méi)亮、USB端口沒(méi)顯示這種條件不夠準(zhǔn)確，因?yàn)檫@些也會(huì)存在其他因素而導(dǎo)致?tīng)顟B(tài)不正常。

接下來(lái)繼續(xù)排查，USB虛擬日志端口選擇的是否正確：

如果虛擬端口沒(méi)顯示出來(lái)：

確認(rèn)下LuatOS開(kāi)發(fā)程序內(nèi)，是否調(diào)用了"pm.power(pm.USB, false)"關(guān)閉usb功能的接口；

AT開(kāi)發(fā)使用AT+ECPCFG?指令查看" usbCtrl "屬性的值是否為2，如果是2代表關(guān)閉了usb功能，需要手動(dòng)設(shè)置下AT+ECPCFG="usbCtrl",0 將usb功能打開(kāi)。

然后重啟模塊，如果還是沒(méi)有端口顯示，就需要從硬件、USB數(shù)據(jù)線、電腦端口方面排查，先做交叉測(cè)試。

有時(shí)還遇到過(guò)從模塊dm、dp飛出的連接線過(guò)長(zhǎng)，

也會(huì)導(dǎo)致usb虛擬端口無(wú)法識(shí)別不能正常顯示：

把dm、dp和usb的連接線整體縮短到30cm左右，端口才能正常顯示；但理論上還是要看使用的USB線和杜邦線的傳輸質(zhì)量是否優(yōu)秀。

有時(shí)使用Win7/Win8的系統(tǒng)，

遇到怎么著都出不來(lái)USB的虛擬端口：

原因是Air780E模塊的USB驅(qū)動(dòng)使用的是微軟系統(tǒng)自帶的USB驅(qū)動(dòng)，所以僅支持在Win10和Win11上驅(qū)動(dòng)。

如果是Win10/Win11上面的方法都嘗試過(guò)，端口也依然沒(méi)有出來(lái)，也不妨用另一臺(tái)電腦試一下看看是否是驅(qū)動(dòng)問(wèn)題，可能電腦上裝的Win10系統(tǒng)是簡(jiǎn)裝版，缺少了一些驅(qū)動(dòng)。

3.3.4 選擇使用DBG_UART串口

** 使用DBG_UART串口流程**

• 抓日志用的USB轉(zhuǎn)TTL的串口工具需要支持6M波特率，電腦上并且裝了對(duì)應(yīng)串口工具用到的驅(qū)動(dòng)（一般從網(wǎng)絡(luò)上或者購(gòu)買商家那里，可以了解到需要用什么驅(qū)動(dòng)）；
• 打開(kāi)設(shè)備端口配置界面；
• 關(guān)閉或打開(kāi)端口：
  如果端口被占用，工具也不會(huì)提示"端口已被占用"，所以如果發(fā)現(xiàn)端口選擇正確，并且日志還是沒(méi)有出來(lái)的話，可以確認(rèn)下日志端口是否有被占用，而導(dǎo)致EPAT沒(méi)有打開(kāi)日志端口。
• Device0、Device1兩個(gè)復(fù)選框，二選其一；
• 打開(kāi)日志輸出端口和修改波特率的界面；
• 選擇日志輸出端口；
• DBG_UART端口波特率輸出可手動(dòng)寫入修改為 6000000（6M） 波特率。

使用DBG_UART串口沒(méi)輸出出來(lái)日志，排除步驟和USB也有點(diǎn)相同之處。

首先確認(rèn)下模塊是否開(kāi)機(jī)：

最直接的方式就是量vbat的電壓是否在4.3v~3.3v之間，并且看VDD_EXT是否有1.8v或3.3v，電壓正常就說(shuō)明模塊是處于開(kāi)機(jī)狀態(tài)了。

其他類似于看網(wǎng)絡(luò)燈沒(méi)亮、USB端口沒(méi)顯示這種條件不夠準(zhǔn)確，因?yàn)檫@些也會(huì)存在其他因素而導(dǎo)致?tīng)顟B(tài)不正常。

接下來(lái)繼續(xù)排查，DBG_UART日志串口選擇的是否正確：

確認(rèn)下LuatOS開(kāi)發(fā)程序內(nèi)是否有通過(guò)云編譯關(guān)閉了uart0的日志輸出；

AT開(kāi)發(fā)使用AT+ECPCFG?指令查看，要DBG_UART0輸出日志，需要幾條指令配置一下：

AT+ECPCFG="logPortSel",1

// 只從UART0輸出日志

AT+ECPCFG=logBaudrate,6000000

// 修改日志輸出波特率為6M

AT+ECPCFG="logCtrl",2

// 輸出log等級(jí)為ALL，全部任何日志都輸出

指令配置完之后重啟模塊，正常來(lái)說(shuō)日志應(yīng)該就可以輸出了。

如果還是沒(méi)有日志，嘗試用sscom這種串口調(diào)試工具打開(kāi)相同的端口，看下是否有日志輸出（正常會(huì)輸出一堆的亂碼）；

沒(méi)有輸出的話，就需要排查下打開(kāi)的端口：

串口接線，比如rx/tx反接一下，有沒(méi)有短路。

并且如果是從預(yù)留的測(cè)試點(diǎn)用杜邦線飛出的DBG_UART_TX和DBG_UART_RX， 那需要注意杜邦線的長(zhǎng)度一定要短，不然也會(huì)影響輸出的日志出現(xiàn)丟失 。

3.3.5 進(jìn)階玩法--兩個(gè)端口都使用

沒(méi)錯(cuò)，還可以同時(shí)使用USB的虛擬日志端口和DBG_UART日志串口來(lái)抓取日志。

這樣做的好處是：

在進(jìn)入休眠場(chǎng)景的時(shí)候，待USB斷開(kāi)，就會(huì)用DBG串口輸出日志，等模塊喚醒時(shí)就會(huì)重新虛擬出來(lái)USB端口，就會(huì)從USB的日志口抓取日志。

如果通過(guò)DBG_UART串口來(lái)抓取非休眠場(chǎng)景的日志：

由于底層業(yè)務(wù)邏輯過(guò)多，各種日志都會(huì)長(zhǎng)時(shí)間大批量輸出，只用6M的波特率，還是避免不了可能出現(xiàn)丟日志的情況。

而用串口抓取休眠中的日志時(shí)，由于一些底層業(yè)務(wù)會(huì)關(guān)閉，輸出的日志相對(duì)并沒(méi)有特別頻繁，所以在休眠中丟日志概率會(huì)小一些。

但兩個(gè)端口同時(shí)使用，

這樣就把兩個(gè)端口的優(yōu)勢(shì)都使用上了：

無(wú)論是休眠場(chǎng)景還是其他業(yè)務(wù)邏輯場(chǎng)景，基本上不會(huì)出現(xiàn)任何日志丟失的情況，但要求就是兩個(gè)端口都要有預(yù)留出來(lái)。

兩個(gè)端口同時(shí)使用流程要點(diǎn)

• 打開(kāi)設(shè)備端口配置界面；
• 關(guān)閉或打開(kāi)端口：
  如果端口被占用，工具也不會(huì)提示"端口已被占用"，所以如果發(fā)現(xiàn)端口選擇正確，并且日志還是沒(méi)有出來(lái)的話，可以確認(rèn)下日志端口是否有被占用，而導(dǎo)致EPAT沒(méi)有打開(kāi)日志端口。
• 日志端口可以同時(shí)打開(kāi)兩個(gè)，一個(gè)用模塊的DBG_UART端口打開(kāi)，另一個(gè)使用USB的日志輸出端口。

AT固件需要設(shè)置以下指令（重啟生效）才能設(shè)置日志端口可以從USB和DBG_UART兩個(gè)端口輸出。

AT+ECPCFG=logPortSel,2

// USB和DBG_UART都允許輸出底層日志

下面兩個(gè)指令如果不配置，那么插入usb不會(huì)進(jìn)入休眠，配置下面指令之后，相當(dāng)于就算接入usb也允許進(jìn)入休眠。

AT+ECPCFG="usbSlpMask",1

// USB不參與休眠投票

AT+ECUSBSYS="VBUSModeEn",1,"VBUSWkupPad",1

// usb的vbus引腳不參與休眠投票

• 打開(kāi)日志輸出端口和修改波特率的界面；
• 選擇日志輸出端口；
• USB的虛擬日志端口不用修改波特率：
• DBG_UART端口波特率輸出可手動(dòng)寫入修改為6000000（6M）波特率。

因?yàn)檫@個(gè)項(xiàng)目沒(méi)有用休眠場(chǎng)景，就直接用USB來(lái)抓日志了。

按照上面的流程接上USB，打開(kāi)日志的虛擬端口，成功看到了有日志出來(lái)。下面只需要掛著等問(wèn)題出現(xiàn)就好了。

有抓過(guò)底層日志的朋友肯定想起來(lái)，

不是還有一步匹配解析日志的數(shù)據(jù)庫(kù)MDB.txt文件嗎？

其實(shí)如果只是導(dǎo)出pcap看網(wǎng)絡(luò)包，不需要去匹配數(shù)據(jù)庫(kù)文件。

?

四、導(dǎo)出pcap文件，查看網(wǎng)絡(luò)抓包

首先在抓取到復(fù)現(xiàn)的日志之后，不要著急，先停止日志打印。

然后在當(dāng)前是SigLogger視圖的日志窗口時(shí)，才能看到并點(diǎn)擊右上角的SigLog菜單欄。

打開(kāi)SigLog菜單欄后，點(diǎn)擊"Export As pcap file"：

選擇一個(gè)導(dǎo)出路徑并起一個(gè)文件名稱， 切記：文件名稱不能和當(dāng)前文件夾內(nèi)的.pcap名稱重復(fù)?。?！ 因?yàn)閷?dǎo)出同名文件，根據(jù)提示點(diǎn)擊覆蓋，但實(shí)際上內(nèi)容卻并不會(huì)覆蓋變化。

隨后點(diǎn)擊保存，即可導(dǎo)出pcap格式的抓包文件。

?

五、通過(guò)Wireshark開(kāi)始分析

好的，網(wǎng)絡(luò)包也抓到了，調(diào)轉(zhuǎn)回來(lái)繼續(xù)分析：

——“TCP長(zhǎng)鏈接，定時(shí)上報(bào)GPS/基站/wifi的定位數(shù)據(jù)，沒(méi)有休眠需求，但時(shí)不時(shí)在發(fā)送數(shù)據(jù)的時(shí)候，會(huì)出現(xiàn)AT+CIPSEND發(fā)數(shù)據(jù)發(fā)著發(fā)著返回+CME: ERROR 3”的問(wèn)題。

先前文章開(kāi)頭已經(jīng)分析出是TCP鏈接出現(xiàn)斷開(kāi)，而導(dǎo)致AT+CIPSEND命令返回+CME: ERROR 3。但還不清楚具體是模塊主動(dòng)斷開(kāi)的，還是服務(wù)器端斷開(kāi)的鏈接。

下面我們就通過(guò)導(dǎo)出的pcap文件，打開(kāi)看一下。

根據(jù)日志的時(shí)間戳看到復(fù)現(xiàn)時(shí)間在18:56.24左右，那我們先定位到這個(gè)時(shí)間附近看一下。

?

結(jié)果確實(shí)找到了[FIN,ACK]請(qǐng)求斷開(kāi)連接的網(wǎng)絡(luò)包，在確認(rèn)下發(fā)出的ip地址是 112.74.41.204 ，目標(biāo)地址是 10.49.81.92 。

怎么判斷哪個(gè)是模塊，哪個(gè)是服務(wù)器端呢？

也很簡(jiǎn)單，還是從上面那張圖片舉例：

流程中現(xiàn)在有檢測(cè)如果發(fā)現(xiàn)AT+CIPSEND發(fā)送失敗，

就發(fā)送 AT+CEREG?、AT+CIPSTATUS ，

等返回結(jié)果為+CEREG:0,1和STATE: TCP CLOSED時(shí)，

就重新建立連接。

從AT流程中看出：

在19:00:12時(shí)有發(fā)送AT+CIPSTART=xxxxxx,xxx，來(lái)建立新鏈接。

從圖片中網(wǎng)絡(luò)包的同一時(shí)間19:00:12，也確實(shí)出現(xiàn)了[SYN]建立連接的請(qǐng)求，發(fā)出的地址是10.49.81.92，那這個(gè)就是模塊端的IP地址了。

以此推斷出：

另一個(gè)112.74.41.204就是服務(wù)器端的IP地址 （一般如果服務(wù)器是自己公司建立維護(hù)的，可以向自己公司的相關(guān)負(fù)責(zé)的同事詢問(wèn)一下，服務(wù)器IP是哪一個(gè)）。

既然找出了發(fā)出[FIN,ACK]請(qǐng)求斷開(kāi)連接的網(wǎng)絡(luò)包是112.74.41.204這個(gè)服務(wù)器端的IP地址，這樣就明白了是服務(wù)器端主動(dòng)把鏈接關(guān)閉的。

不過(guò)正常來(lái)說(shuō)，被動(dòng)斷開(kāi)連接模塊應(yīng)該會(huì)出現(xiàn)" CLOSED "的URC上報(bào)，但為什么沒(méi)。。。

哦~ 原來(lái)有上報(bào)啊，是我忘記加在收到CLOSED的URC上報(bào)后，嘗試重連的邏輯了。

那這個(gè)就很簡(jiǎn)單了，出現(xiàn)斷鏈之后：

先通過(guò)AT+CEREG?獲取到模塊已成功注網(wǎng)的狀態(tài)，

然后再發(fā)送AT+CIPSTART=xxxxxx,xxx做重連。

**最終，導(dǎo)致斷開(kāi)連接的這個(gè)“罪犯”找到了

——是服務(wù)器的問(wèn)題。**

不過(guò)我們用的服務(wù)器，是老板找的第三方。在拿出這個(gè)網(wǎng)絡(luò)抓包（證據(jù)）之后，以為能知道是什么原因呢，結(jié)果一直在"踢皮球"，說(shuō)他們也是負(fù)責(zé)代理，他們也要去確認(rèn)……

哎，溝通起來(lái)那是可真累啊~一整天都過(guò)去了，也不知道是啥原因。

由于項(xiàng)目趕時(shí)間，解決完這個(gè)問(wèn)題后，又要看下一個(gè)問(wèn)題了！

?審核編輯 黃宇