物聯網設備通訊故障檢測技術與解決方案

高小淋

摘要：隨著時代的進步以及物聯網技術的快速發展，以智能家居為代表的各種物聯網產品應運而生。依托智能手機實現遠程數據采集、環境監測及設備控制成為智能家居發展的新風尚。與此同時，設備的通訊故障問題也日益嚴重。當前大部分一線智能家居售后維護工程師能夠對設備的硬件故障進行排查，但是在網絡通訊故障方面卻顯得蒼白無力。如何利用網絡技術檢測定位故障并排除故障成為一道新的技術難題。本文以真實案例講述智能門禁通訊故障排除的過程，分析了可能導致網絡通訊故障的原因、排查的步驟及處理措施。

關鍵詞：智能門禁;通訊故障;網絡診斷;wireshark抓包

中圖分類號：TP393? ? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2021）09-0210-03

開放科學（資源服務）標識碼（OSID）：

1智能門禁及故障情況說明

聯享家云可視對講門禁系統是一套融合數字網絡、手機移動可視對講和門禁管理為一體的典型的物聯網通訊及控制系統，由門禁、App、云平臺三部分組成。其工作原理如下：智能門禁接入局域網，經寬帶營商的線路出口接入云平臺，平臺上部署云對講應用系統后臺，負責智能手機與智能門禁之間的數據交換及控制管理。智能手機上安裝App，用戶通過賬號注冊將房號及手機號等信息捆綁登記到云平臺。訪客在智能門禁中輸入用戶房號后向用戶手機App發起呼叫，用戶接聽電話即可進行可視對講，并可通過操作實現一鍵遠程開門。

本案例使用的智能門禁是聯享家JKD01-V2001（GSM），安裝在如圖1所示的網絡拓撲環境中，出現智能門禁撥號接通手機后，手機顯示計時通話狀態，而門禁無聲音，智能手機App上無視頻也無聲音，但手機又可以正常控制門禁開門的情況。

2故障分析，排查步驟及處理措施

2.1檢查智能門禁接線

在進行智能門禁故障檢修前，先確保設備完好，安裝、接線正確，避免因線路錯接、漏接、斷路或短路導致設備異常。可根據《產品安裝說明書》檢查智能門禁線路，同時觀察設備上的信號燈提示，比如：亮屏說明通電正常，網口亮綠燈說明網絡連接正常等。

2.2檢測網絡環境

2.2.1檢測網絡接入端

排查設備在網絡接入端的問題，確保智能門禁已正常接入局域網并能順利訪問外網，以排除故障是由本地網絡線路故障、交換機或路由器配置錯誤、網絡中存在類似ARP病毒等原因引起的故障。

檢測的方法是：在智能門禁的網絡接入端，使用一臺PC與智能門禁接入同一臺智能交換機，交換機再上接到路由器。PC與智能門禁的IP設置為同一網段。使用ping命令檢查PC與智能門禁的連通性以及內網與外網的通信是否正常;使用nslookup命令測試DNS解析是否正常;使用tracert命令檢查數據包從內網通向外網的路徑是否正常。

測試結果中，PC能ping通智能門禁（IP）說明PC與智能門禁同在一個局域網。PC能ping通電信的DNS服務器說明內外與外網連通。為了確保內網與外網連接的穩定性--沒有丟包，可以使用ping 114.114.114.114 –t命令測試一段時間，若沒有出現“request timeout”或“請求超時”的提示說明內網與外網的連通性是良好的。使用nsloopup命令進行域名“www.baidu.com”解析成功說明DNS沒問題。通過tracert路由跟蹤可以發現，智能門禁從內外通向外網需經過路由器（192.168.0.1），區域網關（192.168.118.254），核心交換機（192.168.254.254）和防火墻（192.168.200.2）等網絡設備，這為后面做設備配置排查提供依據。

由此可見，智能門禁在網絡接入端是沒有問題的，且與外網連通正常。這里需要注意的是，在實際應用中大部分基于TCP/IP的物聯網設備是使用靜態IP的，這樣可以方便根據ip規劃進行設備管理。

2.2.2檢查上網行為管理攔截

上網行為管理是對內網用戶上網行為進行監督和管控的設備。通常網絡管理員會針對某些網段或ip執行一定規則的管理策略。比如，為了禁止在工作或學習時間使用迅雷、電驢、BT下載以及PPS、PPTV、迅雷看看等軟件，網絡管理員往往會在上網行為管理中對P2P應用、P2P流媒體、Web流媒體等進行限速或禁用，從而誤將智能門禁與手機通訊時傳輸的視頻和音頻進行限制。

通過查看上網行為管理的應用控制策略和智能門禁上層路由（IP）的行為日志，在應用控制策略中并沒有直接禁止智能門禁視頻和音頻傳輸的配置。考慮到上網行為管理還可能配置了其他隱性的管控細則，為了絕對排除故障是由上網行為管理的管控策略引起的，這里將智能門禁上層路由的IP加入白名單。經測試，故障依舊。

2.2.3檢查防火墻攔截

為了網絡的安全性，企業和單位一般都安裝有防火墻，實現對內網設備的安全防護。本案例中部署的是深信服下一代防火墻NGAF，防火墻采用網關模式進行部署。在該模式下，網絡中的所有流量都會經過防火墻處理，可以實現對內網設備進行流量管理、行為控制、安全防護等。作為出口網關，防火墻的安全功能可保障網絡安全，Nat功能可代理內網用戶上網、服務器發布，實現路由功能等。

本案例中智能門禁系統的可視對講和控制功能是基于SIP 協議實現的，而SIP是用來建立、修改和結束多媒體會話的應用層協議，其主要功能有：

1）用戶定位：確定用于通信的終端;

2）用戶可用性：確定被呼叫者參加通信的意愿;

3）用戶能力：確定使用的媒體和媒體參數;

4）會話建立：“響鈴”方式建立會話;

5）會話管理：包括傳輸和終止會話、修改會話參數以及調用服務。

如果防火墻沒有開通SIP端口，那么智能門禁與智能手機之間就無法建立通訊。經核查，確定在防火墻上已開通SIP端口后發現故障依舊。

2.3檢測手機端

2.3.1檢測手機網絡環境

智能手機通常使用WIFI或4G聯網。在WIFI環境下，網絡通信是受其所處局域網和運營商提供的寬帶服務影響的。為了規避局域網復雜的網絡環境，對智能門禁進行有效的故障排查，建議用戶使用4G網絡進行測試。同時要確保在使用環境下4G網絡通暢。這里需要注意一點，并不是4G信號滿格就說明網絡質量就一定很好。4G信號滿格也可能會出現網“卡”的現象。這可能是因為在人口密集的地區有太多的網絡用戶接入到同一個基站，基站的容量是有限的，用戶量越大就越容易造成信號擁堵。

可以使用測速大師App對手機的4G網絡進行2次以上的測試（第1次的測試結果通常不太準確），觀察網絡上傳和下載的速率、延時、抖動和丟包率等信息。除了網絡上傳和下載的速率直觀上可以理解外，一般來說，在延時方面：150ms以下的時延，對于大多數應用來說是可接受的。150～400ms之間的時延，在用戶預知時延狀況的前提下可以接受。大于400ms的時延不可接受;在抖動方面：抖動小于80ms是比較好的，抖動在300ms以下是可以接受的，大于500ms是不可接收的;在丟包方面：丟包率小于5%是比較好的，丟包率大于10%時，已不能接受。

從實地環境測試結果發現，手機當前4G網絡的丟包率較高。對視頻圖像來說，丟包率高會使視頻通話中出現視頻圖像馬賽克、視頻局部變形，圖像模糊、圖像靜止有聲音、圖像閃爍等情況;對音頻來說主要就是音頻失真、間斷、間歇性噪音等。嚴重的丟包甚至會導致視頻音頻中斷。這時，需要更換一個環境再進行測試，結果故障依舊。

2.3.2檢查智能門禁App設置

智能門禁App上有“免打擾”設置功能，如果用戶設置了免打擾時段，那么在該時段內所有的門禁呼叫對講，App將自動拒絕，被拒絕的來電會記錄在訪客記錄中。經檢查，當前智能門禁App上并沒有進行“勿擾設置”。

2.4檢測寬帶運營商

由寬帶運營商導致的設備通訊故障的概率是比較低的，但是這種情況一旦出現，使用常規的檢測手段是很難找到依據。這時，可以使用端口鏡像+wireshark抓包分析的方法來尋找問題的蛛絲馬跡。

首先，需要一臺智能交換機。這里以H3CE528交換機為例，在本案例中智能門禁和PC分別接到交換機的9號端口和10號端口上。

其次，對交換機進行端口鏡像配置，具體如下：

System-view//進入系統視圖。

mirroring-group1mirroring-portGigabitEthernet1/0/9both//創建端口鏡像組1，并將9號端口設置為被鏡像端口，對該端口發送和接收的報文進行鏡像。

mirroring-group1monitor-portGigabitEthernet1/0/10//將10號端口設置為鏡像目的端口。

displaymirroring-group1//查看端口鏡像組1的信息。

這樣，源端口（GigabitEthernet1/0/9）的報文就會被鏡像到目的端口（GigabitEthernet1/0/10）上。連接在目的端口上的PC就可以使用wireshark對這些報文進行監控和分析。

第三，啟動wireshark抓取PC網卡的數據包。用戶使用智能門禁撥號呼叫業主，業主在智能門禁App上接通電話，雙方嘗試進行語音交流，業主嘗試點擊“開門”，通話若干秒后關閉通話，wireshark停止抓包。通過wireshark過濾器使用ip.addr == 192.168.0.233過濾規則篩選出智能門禁收發的所有數據包進行分析。

如圖2所示，從sip發送INVITE消息建立一個會話請求到發送BYE消息結束會話的過程可見，wireshark抓到了一個完整的會話過程。這就可以解釋智能門禁能成功呼叫業主手機并建立通話，手機顯示計時通話狀態的原因。

再來看看遠程開門，通過wireshark過濾器使用“ip.addr == 192.168.0.233 andxml”過濾規則篩選出基于XML消息體的sip消息。

從圖3抓取的數據包MessageBody中的MESSAGE可以發現，智能門禁收到了遠程控制開門的指令，這也就解釋了手機App能遠程控制開門的原因。

那視頻和語音的通訊情況呢？從圖4的抓包結果中發現智能門禁與流媒體服務器在進行通訊時，只有從智能門禁發出的H264視頻流和RTP語音流。流媒體服務器從業主手機App上傳送過來的語音流并沒有轉發過來。這只能解釋智能門禁獲取不到語音的原因，并不能解釋業主手機App獲取不到智能門禁視頻和語音的原因，畢竟從報文上看，智能門禁是完成了上傳視頻和語音的工作。手機App上沒有視頻和語音，在排除流媒體服務器故障的前提下，很可能就是寬帶運營商方面出現了問題。

最后，根據智能門禁所處的網絡拓撲環境，該網絡中存在廣州寬帶和中國電信的雙出口。通過檢查路由配置發現，局域網中的設備是根據vlan決定使用哪個寬帶運營商出口的。智能門禁的上層路由歸屬在vlan3，使用的是廣州寬帶的出口，vlan2是中國電信的出口。那么只需要切換vlan即可實現寬帶出口的切換。以華為S5720交換機為例，配置命令如下：

lsystem-view //進入系統視圖

linterface GigabitEthernet 1/0/9? //進入智能門禁歸屬的交換機端口9

lport link-type access? //將端口類型設置為access

lport default vlan 2? //將端口劃分到以中國電信為出口的vlan2中

然后再通過wireshark抓包分析，如圖5所示：

發現智能門禁依舊沒有獲取到流媒體服務器轉發的H264視頻流，但是獲取到了RTP語音流。智能門禁沒有獲取到視頻流是因為該設備上沒有視頻輸出的功能，這是智能門禁系統和產品設計上的問題。但是此時智能門禁已經可以與業主手機App進行雙向的語音通訊，業主在手機App上也可以看到智能門禁上傳過來的視頻信息。由此得出結論，智能門禁可視對講故障的根源就是寬帶運營商的規則過濾或攔截造成的。

其實，在本案例中，智能門禁通訊故障的解決方案還有很多。比如可以將智能門禁連接WIFI路由器，路由器再橋接到手機熱點使用4G網絡進行通訊也是可以的。基于篇幅，這里就不再展開論述。

3 總結

通過這個案例，我們發現物聯網設備通訊故障的檢測和故障排除是有章可循的。根據設備所處網絡環境的不同，解決方案會有所差異，不管問題有多難多復雜，“只要耐心不滑坡，辦法總比困難多”。

【通聯編輯：聞翔軍】