PCAP結構pcap_pkthdr LEN VS caplen

我們使用嗅探的libpcap在linux上我們得到的每個數據包的報頭包看起來像：PCAP結構pcap_pkthdr LEN VS caplen

struct pcap_pkthdr { 
     struct timeval ts;  /* time stamp */ 
     bpf_u_int32 caplen;  /* length of portion present */ 
     bpf_u_int32 len;  /* length this packet (off wire) */ 
};

現在，這是我的理解是caplen是數據的長度我們已經捕獲了，而 len是線路上數據包的長度。在某些情況下（例如，當打開pcap設備時，snaplen設置太低），我們可能只捕獲部分數據包，該長度將是'caplen'，而'len'是原始長度。因此，caplen應該等於或小於len，但從不大於len。

這是一個正確的理解？我們在某些機器上正在搜尋caplen> len

來源

2009-09-29 nos

您應該在pcapr.net上發佈觸發此問題的pcap，這將非常有趣。 Personnaly，我從來沒有見過。 – bortzmeyer 2009-09-29 20:42:37

您的理解是正確的，至少基於pcap手冊頁。

caplen是捕獲中可用的數據量。 len是數據包的實際長度。

我不知道任何情況下，會給你一個caplen> len。我通常覺得他們是平等的，因爲我的脾氣足夠高。

來源

2009-09-29 16:11:30 Jason

是的，你的理解是正確的caplen總是比len小。有時我們不需要捕獲整個數據包。但是爲什麼你不能抓住整個數據包呢？因爲在一個沉重的網絡流量，這不會是一個好主意。如果我們不捕獲電線上出現的整個數據包，我們是否真的會丟失寶貴的數據？不。實際上它取決於你的目的，如果你只是想根據協議和應用程序對數據包進行分類，你只需要大約14個字節（以太網）加上20個字節（IP）+另外20個（Tcp）因此您顯然只需要54個字節的數據來根據協議對數據包進行分類，因此在將處理大小從pcappkthdr-> len減少到pcappkthdr-> caplen時節省了大量的負載和時間。

如果標頭在數據包被破壞（意味着如果頭長度值以某種方式混亂），則捕獲的長度將大於數據包的實際長度。

來源

2013-01-02 16:22:25 wanttomasterpython

如果caplen> len，那是個bug;你使用的是什麼版本的libpcap？

來源

2013-01-05 22:21:28

PCAP結構pcap_pkthdr LEN VS caplen

回答

相關問題