2013-08-29 32 views
1

我有一個pcap的各種類型的流量超過udf的802.11(wifi)通過。由於MTU,udp(或更確切的說IP)會分割無線包。我目前使用SharpPcap讀取並嘗試訪問wifi流量,並且遇到了手動重新組裝udp數據包的問題。重新組合零碎的UDP數據包

我看到兩個選項,我想檢查它們是否可能,最好的解決方案或是否有某些我忽略的東西。最終,我將訪問通過UDP(唯一提及的那個)流式傳輸給我的實時饋送(相同格式,通過UDP的WiFi),但出於測試目的,我必須使用pcap。

我可以手動加載pcap文件,通過片段偏移量和數據包ID重新組裝它,使狀態機跟蹤所有數據包。或者我可以嘗試避免重組,(我認爲套接字應該爲我做)加載pcap文件,輸出到本地主機上的原始套接字,並監聽本地主機上的UDP套接字。我避免第一個,直到真正有必要(是嗎?),第二個似乎應該工作,但不是。我已經完成了所有這些設置,但數據包仍然按照字節數組的形式一個接一個地發送和接收 - 並且被分割。

難道這是因爲IP層仍然包含原始捕獲的IP目標地址和端口(這是不同的)?我嘗試在發送之前更改這些內容,儘管我沒有更改校驗和,但它仍然是通過分片來完成的。

回答

1

進入您的舊問題尋找解決方案,我自己的問題進行碎片整理。

我瞭解它的方式 - 由於您正在執行數據包捕獲/ pcap讀取,您必須自己對IP數據包進行碎片整理。如果你是一個真正的應用程序在網絡上通信,你的操作系統的IP堆棧會爲你做這件事,你可以按原樣讀取數據。但是數據包捕獲發生在重組之前。你看到的是數據包在線路上傳輸(或在你的情況下)。

碎片整理在理論上相對容易 - 具有相同ID,源/目標IP地址和協議類型的IP數據包屬於一個整體。第一個數據包的碎片偏移量爲0,「More fragments」字段設置爲1.下一個數據包(如果有的話)將「更多碎片」設置爲1,並且爲非零偏移量。最終數據包將具有非零偏移量,並且不會設置「更多片段」。

以某種方式擺脫重複,按偏移排序。每個數據包的有效載荷在packet.fragmentationOffset * 8處進入最終緩衝區。使用這些信息來計算最終的數據包大小也是微不足道的。

更詳盡的解釋可以在這裏找到: http://en.wikipedia.org/wiki/IPv4#Reassembly

我知道你有可能在很長一段時間移動前,但也許這可以幫助別人尋找相同的信息。