物聯網設備的連接問題的支援手段

2020 年 3 月 11 日
筆記

| 導語物聯網支援中, 設備的連接問題檢查是個很麻煩的事情。其它的領域無論前端還是後台開發, 一些疑難問題都有很多的工具輔助判斷問題, 比如抓包就是很方便的方式。但是物聯網設備特別是單片機, 本身資源有限, 一般來說, 很難進行抓包(特別是走蜂窩網路的設備) , 日誌也很受限。

主要的麻煩

物聯網支援中, 設備的連接問題檢查是個很麻煩的事情. 無論前端還是後台開發, 一些疑難問題都有很多的工具輔助判斷問題, 比如抓包就是很方便的方式, 但是物聯網設備特別是單片機, 本身資源有限, 一般來說, 很難進行抓包, 日誌也很受限.

騰訊物聯網開發平台本身為物聯網開發準備了很多的措施來幫助設備開發者來定位問題, 比如通訊日誌等, 但是一切都需要一個前提, 就是設備正常連接了騰訊雲物聯網的 MQTT 服務, 沒有連接上的話, 大部分的手段都難以使用. 而設備大部分都很難抓包, 所以定位問題變得很困難.

用戶連接失敗, 可能的原因非常多, 在實際支援的案例中, 碰到過:

網路問題, 比如運營商屏蔽了IP的訪問, 比如流量受限
設備的軟體問題, 比如客戶端的連接參數不正確等 , 比如客戶端因為C程式碼快取溢出, 導致有時候連接的上, 有時候失敗
設備的通訊模組故障或者bug等

解決的辦法

這些問題很多情況下需要tcpdump抓包才能知道問題所在, 但是實際場景中, 設備就一個開發板+模組, 走的是蜂窩(2G/3G/4G) 線路, 想抓包都沒有辦法抓, 假如在服務端抓包的話, 現網幾百萬設備, 生產環境抓包本身就不是一個靠譜的事情.

在實踐中, 我們一般推薦採用TCP代理連接服務的方式, 在代理伺服器上抓包來幫助診斷問題:

具體步驟

找一台公有雲CVM, 安裝 nginx 服務
listen 1883 埠並代理到騰訊雲的服務

配置代理 MQTT 1883 埠 , 騰訊的物聯網開發平台和物聯網通訊的域名都是 <產品ID>.iotcloud.tencentdevices.com

然後CNAME 到 iothub.msf.tencent-cloud.com , 我們代理這個即可

客戶設置連接到該 CVM 的 IP地址 , 韌體其它的邏輯都不需要改動然後該 CVM 上針對 1883 埠抓包, 就可以判斷連接問題了

MQTT是TCP長連接服務, proxy_timeout 設置不要太小了, 否則會斷開

    vi /etc/nginx/nginx.conf       stream {           upstream hub_host_1883 {              hash $remote_addr consistent;              server iothub.msf.tencent-cloud.com:1883 weight=5 max_fails=1 fail_timeout=10s;           }           upstream hub_host_8883 {              hash $remote_addr consistent;              server iothub.msf.tencent-cloud.com:8883 weight=5 max_fails=1 fail_timeout=10s;           }           server {              listen 1883;              proxy_connect_timeout 3s;              proxy_timeout 600s;              proxy_pass hub_host_1883;           }       }      }

其它的檢查手段

只需要設備本身能夠連接物聯網開發平台發送消息, 物聯網開發平台(https://console.cloud.tencent.com/iotexplorer/)本身提供了很多方法來檢查設備通訊