奇怪的事情正在發生,威脅正在出現,我們需要解決這個問題;
情況:
我們的裝置(網路攝影機)透過網路將視訊串流傳輸到錄影機/伺服器(使用 Live555 / WIS Streamer)。影片是UDP資料包。
在使用特定伺服器的特定網站上,Live555 串流媒體的一個執行緒每隔一段時間(約 24 小時)就會在發送影片時鎖定。其他線程繼續運行,我們仍然可以透過 IP 連接到攝影機 - 查看其中的網頁、PING 它等。
我們懷疑: 伺服器;它有 2 個網路連接埠並將它們聚合起來 - 它有兩個 MAC,但有一個 IP 位址。在進行wireshaking時,我們看到攝影機流向一個連接埠(我們稱之為A),然後我們從另一個連接埠(我們稱之為B)獲得一個ARP,我們的裝置停止向MAC A噴射封包,向線路上噴射一個資料包到 MAC B,然後似乎停了下來。
更多資訊:伺服器似乎損壞了來自「錯誤」連接埠的ARP 封包,可能是由於配置錯誤等原因,但這些封包仍然會被我們的裝置讀取並執行操作,可能是由於我們的驅動程式或核心網路配置錯誤或跳過校驗和以節省 CPU 週期。
因此,這種混亂的情況引出了幾個問題:
- 我應該在核心網路程式碼中的哪裡檢查資料包校驗和或啟用檢查?我們的硬體是固定的,作為嵌入式設備,因此對驅動程式進行調整並不是最糟糕的主意。
send()
有人能猜出當進程不斷在連接埠上獲取資料並且 ARP 表在其下方移動時導致進程鎖定的故障機制嗎?
編輯新增:我們現在懷疑 ARP 並沒有真正損壞,只是 Wireshark 沒有正確識別資料包(它認為資料包足夠長,必須有一個 FSC 字,但我們現在認為它只是零填充)。這就只剩下這個問題的第二部分了:我們能做些什麼來防止 ARP 表中的這種變更導致傳輸進程崩潰?
編輯以進一步添加:我不希望人們認為我忽略了有關連接埠狀態或進程狀態的問題,這個問題很少發生(平均可能每 24 小時一次),並且僅發生在我們無法輕鬆訪問的一個(遠端)安裝上,我們正在努力在實驗室中複製它,以便我們可以進行更詳細的診斷,但係統看門狗會在問題發生後約3 分鐘內重置,因此當我們收到訊息時,它已經重新啟動並開始正常工作。
編輯新增 Wireshark 訊息:我不確定這裡總結wireshark捕獲的最佳方法(很難上傳〜1Tb捕獲的數據包!)但我會嘗試。Cam:X
&Cam:Y
是兩個 RTSP 視訊串流,由兩個相同的 Live555 WIS Streamer 實例從不同連接埠傳輸。伺服器「A」和「B」是伺服器上兩個網路卡的 MAC。
資料包的順序如下:
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
此時或附近,流中沒有其他資料包。英特爾 ANS 資料包並不總是與來自 NIC 的 ARP 一致,但為了完整起見,我想將它們包括在內。
這個問題似乎對時間非常敏感,我們定期從伺服器看到這些「團隊」ARP,並且只有一次它們才會給我們帶來問題 - 就好像網路堆疊程式碼中有一個特定點對ARP 表改變。失敗的流實例並不總是相同,特別是另一個實例(以及所有其他網路流量 - HTTP 等)繼續正常工作。
聽起來,成組的 NIC「不應該」像這個會話中那樣進行 ARP,但是當流量全部為 UDP 時,它們當然不會知道任何會話。
答案1
好吧,如果只是給一些關閉為此,客戶重新配置了他們的狡猾的網卡並且一切正常,因此不幸的是,對於好奇的人來說,這意味著沒有人會付錢給任何人來仔細研究可以採取哪些措施來解決該問題。