本地主機上的OSI層

Question

我寫了一個小應用程序來試圖顯示捕獲的數據包的協議頭。我的所有數據包都用libpcap的pcap_loop捕獲。我的程序工作方式如下：我根據if_ether.h ip.h和tcp.h中定義的結構編寫了自己的頭文件。 pcap_loop設置一個字符指針指向數據包的開頭，然後我逐步遍歷數據包，每次都轉換爲適當的結構，然後按指針的大小遞增指針。現在重要的是要記住我的問題不是代碼特定的;我的代碼可以工作，但是有些邏輯缺陷我不能解決;請記住我的數據包是通過同一臺機器，不同的端口發送的（我使用telnet發送數據到微型python服務器）：

1.當報文發送時，以太網報頭不顯示任何看起來正確的內容通過本地主機（當我使用我的程序上的互聯網數據包，MAC地址dos doseded雖然）

2.通過反覆試驗，我已經確定結構iphdr啓動後，數據包緩衝區開始剛好16個字節，與預期的14字節相反，以太網報頭的大小爲

那些觀察結果導致我提出以下問題： 當數據包是森通過本地主機，我們是否使用第二層協議？ 是否有任何分離數據包頭的內容？ 在ip.h和tcp.h中定義的iphdr和tcphdr結構是否已過時？

Answer 1

當數據包通過本地主機發送時，我們是否在第2層上使用了另一種協議？

確實沒有第2層協議，因爲沒有真正的網絡適配器。

但是，有一些虛假的第2層標頭提供給捕獲流量的程序。什麼虛假頭被提供與操作系統有關。

在Linux上，虛假的第2層報頭是假以太網報頭。

在* BSD，OS X，iOS和我認爲的Solaris 11上，它們是DLT_NULL或DLT_LOOP標頭，如the list of libpcap/WinPcap/pcap/pcap-ng link-layer header types中所述。

但是：

經過反覆試驗，我已經確定iphdr包緩衝

開始後正好是16個字節開始，如果你在捕捉結構「任何「設備，頭文件是DLT_LINUX_SLL headers，它們是16字節長。

如果您正在使用PCAP或任何PCAP包裝，你MUST，無一例外地打電話pcap_datalink()，或包裝的當量，試圖解析任何包您捕獲或從SAVEFILE讀取之前。您絕不能假設數據包將具有ANY特定的鏈路層報頭類型。