tcpdump的：精確匹配數據包長度

越接近我想出了是這樣的：

tcpdump -ni lo -ttt dst port 1337 and greater 16

如果我添加其他過濾器，以配合我會喜歡：

tcpdump -ni lo -ttt dst port 1337 and greater 16 and not greater 17 
tcpdump -ni lo -ttt dst port 1337 and \(greater 16 and not greater 17\) 
tcpdump -ni lo -ttt dst port 1337 and greater 16 and less 16

它根本沒有顯示任何數據包。

Althought，使用：

tcpdump -ni lo -ttt dst port 1337 and less 16

似乎並沒有工作都不是，我實際上游蕩，如果少濾鏡......

歡迎任何幫助:)

來源

2012-10-25 naab

我認爲長度包括所有的頭文件，而不僅僅是TCP數據，我不認爲你可能會看到只有16字節的數據包，以太網幀中的TCP段有18字節的以太網頭和尾部，至少16字節的TCP頭（通常更多的是因爲TCP選項） – Barmar

我應該精確地知道tcpdump將我發送的數據包看作是長度爲16字節的數據包，這就是爲什麼我要使用數據包長度對它們進行過濾的原因。通常的TCP層從總長度沒有？還是它顯示不相關的長度？ – naab

是的，tcpdump做了很多decodi在它顯示給你之前，並顯示特定於協議的數據。但是這些過濾器是由一個對協議不太瞭解的底層庫實現的。 – Barmar

正如Barry Margolin指出的那樣，greater運算符檢查整個數據包的長度，包括所有頭部。 16個字節的TCP有效載荷加上20個字節的TCP報頭（這是最小的TCP報頭長度，沒有選項）加上20個字節的IPv4報頭（這是最小的IPv4報頭長度，沒有選項）加上14個字節的以太網報頭，例如， 70個字節。

我從「lo」中猜測你在Linux上捕獲並捕獲在回送接口上，在這種情況下數據包有一個（假的）以太網頭。

68字節是舊版tcpdump默認的快照長度，當沒有IPv6支持時，所以可能被報告爲68的長度是捕獲的長度，最後2個字節被截斷。嘗試運行帶有標記-o 0的tcpdump（除非它是一個確實是舊版本的tcpdump，則快照長度爲0意味着「將快照長度設置得非常高，以便數據包不會被切斷）。

來源

2014-04-10 02:00:15

好吧，它確實有效。數據包長度通過「-v」標誌可見。

來源

2012-10-25 12:33:37 naab

tcpdump的：精確匹配數據包長度

回答

相關問題