2016-05-07 19 views
0

我已經找到了什麼代碼解析IP地址(v4)在kernel source tree數據包。此功能,ip_rcv,可以以高度的確定性的檢測分組是否正確與否,在評論中的一個被概述:Linux內核如何找到正確的偏移來解析IP數據包?

  1. 長度至少一個IP報頭
  2. 版的尺寸4
  3. 校驗和正確。 [供以後速度優化,跳過回送校驗]
  4. 不有假的長度

畸形數據包被丟棄簡單。這個函數似乎得到了一堆應該類似於IP數據包的字節,但是如果一些惡意的演員會偷偷在線上多出一個字節呢?如果處理不正確,ip_rcv從現在開始接收的所有字節塊將開始1個字節關閉,並且不再能夠重建正確的IP分組。我假設內核做的比嘗試開始分析IP數據包的所有不同的字節偏移更聰明。究竟是什麼,我無法找到。任何人都可以對此有所瞭解嗎?

回答

2

我沒有花時間看看內核代碼,但大多數協議棧都將通過在先前的堆棧位置之後立即解析數據而不是通過搜索數據來工作。

在以太網的情況下,以太網幀頭通常爲14個字節大小。它可以變化,但是頭部本身在必要時指示etherType字段中的不同長度。在此示例中,NIC(網絡接口卡)將接收以太網幀。如果幀指向此NIC,則從NIC驅動程序傳遞到IP堆棧的數據將是一個以太網幀,其中包含此14字節的標頭,緊接着是IP標頭(如果它是第4版IP,則第一個半字節將爲4)頭部例如)。

同樣,我沒有看在網絡堆棧的代碼,但有兩種常見的情況下,這裏有:

1)IP堆棧被告知這是以太網幀,只需要解析的以太網幀報頭其長度和下一個字節必須是IP標頭或數據被視爲不是IP幀。

2)IP堆棧被賦予一個指向緊接在以太網幀頭之後的數據開始的指針,然後IP堆棧開始在該位置解析。

+0

感謝您的回答。在這種情況下,IP堆棧依賴於底層協議是很好的。什麼情況下使用「tun」設備? Tun設備是IP-in和IP-out,除了兩個隧道傳輸應用程序之間的協議外,沒有其他任何設備保護IP數據包的完整性。如果這條隧道是建立在一個不可靠的協議之上的,那麼所有的希望都會丟失嗎? – delins

+0

以太網在每個以太網幀上都有CRC校驗。如果接收到的幀沒有通過CRC校驗,那麼幀將被丟棄並且不會被髮送到任何底層協議。我會假設你可能使用的任何協議都應該做同樣的事情。如果不是,那麼IP校驗和會希望找到不好的數據並丟棄它。因此,所有的希望都不會丟失,IP在它沒有收到它期望的數據報時會重試。 – Russ