基于網絡設備驅動的IP隧道應用軟件

文/黃騰 鄭凱 姜孝偉

在TCP/IP世界中，以太網IP數據報的封裝是在RFC 894[Hornig 1984]中定義的。前面12個字節是硬件地址（即MAC地址）。

對MAC地址的提取是IP隧道的關鍵技術。在Windows操作系統中，可以通過綁定底層適配器來提取服務端和客戶端的MAC地址。但是，在VxWorks嵌入式實時操作系統中，沒有相應的底層適配器應用函數。通過鉤子函數可以鉤取MAC地址，但鉤子函數本身屬于黑客機制，具有一定的風險。

本文通過開發SENS中的MUX層，對網卡底層原始數據進行提取，從而獲取服務端與客戶端的MAC地址，實現IP隧道技術。

1 可裁減的增強型網絡堆棧

SENS獨立于硬件設備接口，由協議驅動程序、多元接口MUX層和END網絡驅動程序組成。

協議驅動程序負責與上層網絡傳輸協議交互。增強型網絡驅動END（Enhanced Network Driver）是一個數據鏈路層驅動程序，它通過MUX層與網絡協議層通信。MUX層作為數據鏈路層和網絡協議層之間的接口，用于管理網絡協議接口和底層硬件之間的交互，將硬件從網絡協議的細節中隔離出來。它是為減弱數據鏈路層與網絡協議層之間的耦合性、提升網絡驅動程序與協議的通信效率而專門增加的一層協議。

2 驅動程序與協議層共享緩沖區

VxWorks網絡協議棧傳輸數據使用的內存，是在VxWorks操作系統啟動進行網絡協議初始化時申請的。VxWorks操作系統提供NetBufLib建立內存節點池，網絡協議棧傳輸數據所需的內存都在這些內存節點池中申請，使用完畢后釋放。

表1：IP隧道業務報文結構

表2：IP隧道應用軟件抓取的MAC地址

NetBufLib使用三種數據結構處理網絡協議棧傳輸的數據：mBlk、clBlk和cluster。其中，cluster保存的是實際的數據，mBlk和clBlk保存的是指向數據的指針，用于管理cluster中保存的數據。

在基于END驅動的VxWorks中，網絡協議通過MUX接口與數據鏈路層進行通信，所有與網絡接口相關的業務都在數據鏈路層驅動中處理，如數據的發送和接收。

3 IP隧道報文結構

在網卡之間搭建IP隧道，對每一個發送的IP報文封裝IP隧道報頭，對每一個接收的IP報文拆解IP隧道報頭。業務報文結構如表1。

4 試驗數據與分析

本文試驗使用計算機和開發板搭建IP隧道。

試驗準備階段，在計算機上安裝“業務模擬與分析系統”終端軟件和UDP數據終端軟件，用于和開發板之間進行數據包的收發。在開發板PPC上加載并運行IP隧道應用軟件。

開機后，計算機和開發板網卡間會進行數據交互，IP隧道應用軟件接收端會抓取開發板網卡收到的最原始數據。提取數據的前12個字節，開發板MAC地址在前（目的MAC地址），計算機MAC地址在后（源MAC地址）。試驗數據如表2。

獲取MAC地址后，在發送端封裝IP隧道報頭，處理時要把上述目的MAC和源MAC對調。

IP隧道應用軟件接收來自“業務模擬與分析系統”終端軟件的數據并通過UDP轉發給UDP數據終端軟件；同時，它通過UDP接收來自UDP數據終端軟件的數據并轉發給“業務模擬與分析系統”終端軟件，從而形成測試回路。

5 結束語

我們進行了10000次開機試驗，試驗數據證明，本文通過開發MUX層抓取網卡底層最原始數據，對服務端與客戶端MAC地址的提取成功率高達100%。同時，在“業務模擬與分析系統”終端軟件中設置數據發送間隔為5ms情況下，回環測試的數據收、發丟包率為0%。試驗數據表明，本文提出的通過開發MUX層實現網卡底層數據抓取的方法可以有效解決VxWorks嵌入式實時操作系統下IP隧道報文的收、發問題，從而保障無線通信。