基於 linux 平臺的 libpcap 原始碼分析
http://blog.chinaunix.net/uid-21768364-id-3244490.html
關於作者: 施聰，成都人，高階程式設計師、網路設計師。從事基於 UNIX/LINUX 下的 c/c++ 程式設計和資料庫建模工作已 10 年。
libpcap 是 unix/linux 平臺下的網路資料包捕獲函式包，大多數網路監控軟體都以它為基礎。Libpcap 可以在絕大多數類 unix 平臺下工作，本文分析了 libpcap 在 linux 下的原始碼實現，其中重點是linux 的底層包捕獲機制和過濾器設定方式,同時也簡要的討論了 libpcap 使用的包過濾機制 BPF。
網路監控
絕大多數的現代作業系統都提供了對底層網路資料包捕獲的機制，在捕獲機制之上可以建立網路監控（Network Monitoring）應用軟體。網路監控也常簡稱為sniffer,其最初的目的在於對網路通訊情況進行監控，以對網路的一些異常情況進行除錯處理。但隨著互連網的快速普及和網路攻擊行為的頻繁出現，保護網路的執行安全也成為監控軟體的另一個重要目的。例如，網路監控在路由器，防火牆、入侵檢查等方面使用也很廣泛。除此而外，它也是一種比較有效的黑客手段，例如，美國政府安全部門的"肉食動物"計劃。
包捕獲機制
從廣義的角度上看，一個包捕獲機制包含三個主要部分：最底層是針對特定作業系統的包捕獲機制，最高層是針對使用者程式的介面，第三部分是包過濾機制。
不同的作業系統實現的底層包捕獲機制可能是不一樣的，但從形式上看大同小異。資料包常規的傳輸路徑依次為網絡卡、裝置驅動層、資料鏈路層、IP 層、傳輸層、最後到達應用程式。而包捕獲機制是在資料鏈路層增加一個旁路處理，對傳送和接收到的資料包做過濾/緩衝等相關處理，最後直接傳遞到應用程式。值得注意的是，包捕獲機制並不影響作業系統對資料包的網路棧處理。對使用者程式而言，包捕獲機制提供了一個統一的介面，使使用者程式只需要簡單的呼叫若干函式就能獲得所期望的資料包。這樣一來，針對特定作業系統的捕獲機制對使用者透明，使使用者程式有比較好的可移植性。包過濾機制是對所捕獲到的資料包根據使用者的要求進行篩選，最終只把滿足過濾條件的資料包傳遞給使用者程式。
Libpcap 應用程式框架
Libpcap 提供了系統獨立的使用者級別網路資料包捕獲介面，並充分考慮到應用程式的可移植性。Libpcap 可以在絕大多數類 unix 平臺下工作，參考資料 A 中是對基於 libpcap 的網路應用程式的一個詳細列表。在 windows 平臺下，一個與libpcap 很類似的函式包 winpcap 提供捕獲功能，其官方網站是http://winpcap.polito.it/。
Libpcap 軟體包可從 http://www.tcpdump.org/ 下載，然後依此執行下列三條命令即可安裝，但如果希望 libpcap 能在 linux 上正常工作，則必須使核心支援"packet"協議，也即在編譯核心時開啟配置選項 CONFIG_PACKET(選項預設為開啟)。
|
|
libpcap 原始碼由 20 多個 C 檔案構成，但在 Linux 系統下並不是所有檔案都用到。可以通過檢視命令 make 的輸出瞭解實際所用的檔案。本文所針對的libpcap 版本號為 0.8.3，網路型別為常規乙太網。Libpcap 應用程式從形式上看很簡單，下面是一個簡單的程式框架：
|
|
檢查網路裝置
libpcap 程式的第一步通常是在系統中找到合適的網路介面裝置。網路介面在Linux 網路體系中是一個很重要的概念，它是對具體網路硬體裝置的一個抽象，在它的下面是具體的網絡卡驅動程式，而其上則是網路協議層。Linux 中最常見的介面裝置名 eth0 和 lo。Lo 稱為迴路裝置，是一種邏輯意義上的裝置,其主要目的是為了除錯網路程式之間的通訊功能。eth0 對應了實際的物理網絡卡，在真實網路環境下，資料包的傳送和接收都要通過 eht0。如果計算機有多個網絡卡，則還可以有更多的網路介面，如 eth1,eth2 等等。呼叫命令 ifconfig 可以列出當前所有活躍的介面及相關資訊，注意對 eth0的描述中既有物理網絡卡的 MAC 地址，也有網路協議的 IP 地址。檢視檔案 /proc/net/dev 也可獲得介面資訊。
Libpcap 中檢查網路裝置中主要使用到的函式關係如下圖：
libpcap 呼叫 pcap_lookupdev() 函式獲得可用網路介面的裝置名。首先利用函式 getifaddrs() 獲得所有網路介面的地址，以及對應的網路掩碼、廣播地址、目標地址等相關資訊，再利用add_addr_to_iflist()、add_or_find_if()、get_instance() 把網路介面的資訊增加到結構連結串列 pcap_if 中，最後從連結串列中提取第一個介面作為捕獲裝置。其中 get_instanced() 的功能是從裝置名開始,找第一個是數字的字元,做為介面的例項號。網路介面的裝置號越小，則排在連結串列的越前面，因此，通常函式最後返回的裝置名為 eth0。雖然 libpcap 可以工作在迴路介面上，但顯然 libpcap開發者認為捕獲本機程序之間的資料包沒有多大意義。在檢查網路裝置操作中，主要用到的資料結構和程式碼如下：
|
|
開啟網路裝置
當裝置找到後，下一步工作就是開啟裝置以準備捕獲資料包。Libpcap 的包捕獲是建立在具體的作業系統所提供的捕獲機制上，而 Linux 系統隨著版本的不同，所支援的捕獲機制也有所不同。
2.0 及以前的核心版本使用一個特殊的 socket 型別 SOCK_PACKET，呼叫形式是 socket(PF_INET, SOCK_PACKET, int protocol)，但 Linux 核心開發者明確指出這種方式已過時。Linux 在2.2 及以後的版本中提供了一種新的協議簇 PF_PACKET 來實現捕獲機制。PF_PACKET 的呼叫形式為 socket(PF_PACKET, int socket_type, int protocol)，其中 socket 型別可以是SOCK_RAW 和 SOCK_DGRAM。SOCK_RAW 型別使得資料包從資料鏈路層取得後，不做任何修改直接傳遞給使用者程式，而 SOCK_DRRAM 則要對資料包進行加工(cooked)，把資料包的資料鏈路層頭部去掉，而使用一個通用結構 sockaddr_ll 來儲存鏈路資訊。
使用 2.0 版本核心捕獲資料包存在多個問題：首先，SOCK_PACKET 方式使用結構 sockaddr_pkt 來儲存資料鏈路層資訊，但該結構缺乏包型別資訊；其次，如果引數 MSG_TRUNC 傳遞給讀包函式 recvmsg()、recv()、recvfrom() 等，則函式返回的資料包長度是實際讀到的包資料長度，而不是資料包真正的長度。Libpcap 的開發者在原始碼中明確建議不使用 2.0 版本進行捕獲。
相對 2.0 版本 SOCK_PACKET 方式，2.2 版本的 PF_PACKET 方式則不存在上述兩個問題。在實際應用中，使用者程式顯然希望直接得到"原始"的資料包，因此使用 SOCK_RAW 型別最好。但在下面兩種情況下，libpcap 不得不使用 SOCK_DGRAM 型別，從而也必須為資料包合成一個"偽"鏈路層頭部（sockaddr_ll）。
某些型別的裝置資料鏈路層頭部不可用：例如 Linux 核心的 PPP 協議實現程式碼對 PPP 資料包頭部的支援不可靠。
在捕獲裝置為"any"時：所有裝置意味著 libpcap 對所有介面進行捕獲，為了使包過濾機制能在所有型別的資料包上正常工作,要求所有的資料包有相同的資料鏈路頭部。
開啟網路裝置的主函式是 pcap_open_live()[pcap-linux.c]，其任務就是通過給定的介面裝置名，獲得一個捕獲控制代碼：結構 pcap_t。pcap_t 是大多數 libpcap 函式都要用到的引數，其中最重要的屬性則是上面討論到的三種 socket 方式中的某一種。首先我們看看 pcap_t 的具體構成。
|
|
函式 pcap_open_live() 的呼叫形式是 pcap_t * pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, char *ebuf)，其中如果 device 為 NULL 或"any"，則對所有介面捕獲，snaplen 代表使用者期望的捕獲資料包最大長度，promisc 代表設定介面為混雜模式（捕獲所有到達介面的資料包，但只有在裝置給定的情況下有意義），to_ms 代表函式超時返回的時間。本函式的程式碼比較簡單，其執行步驟如下：
為結構 pcap_t 分配空間並根據函式入參對其部分屬性進行初試化。
分別利用函式 live_open_new() 或 live_open_old() 嘗試建立 PF_PACKET 方式或 SOCK_PACKET 方式的 socket，注意函式名中一個為"new"，另一個為"old"。
根據 socket 的方式，設定捕獲控制代碼的讀緩衝區長度，並分配空間。
為捕獲控制代碼 pcap_t 設定 linux 系統下的特定函式，其中最重要的是讀資料包函式和設定過濾器函式。（注意到這種從抽象模式到具體模式的設計思想在 linux 原始碼中也多次出現，如 VFS 檔案系統）
handle->read_op = pcap_read_linux； handle->setfilter_op = pcap_setfilter_linux；
下面我們依次分析 2.2 和 2.0 核心版本下的 socket 建立函式。
|
|
比較上面兩個函式的程式碼，還有兩個細節上的區別。首先是 socket 與介面繫結所使用的結構：老式的繫結使用了結構 sockaddr，而新式的則使用了 2.2 核心中定義的通用鏈路頭部層結構sockaddr_ll。
|
|
第二個是在 2.2 版本中設定裝置為混雜模式時，使用了函式 setsockopt()，以及新的標誌 PACKET_ADD_MEMBERSHIP 和結構 packet_mreq。我估計這種方式主要是希望提供一個統一的呼叫介面，以代替傳統的（混亂的）ioctl 呼叫。
|
|
使用者應用程式介面
Libpcap 提供的使用者程式介面比較簡單，通過反覆呼叫函式pcap_next()[pcap.c] 則可獲得捕獲到的資料包。下面是一些使用到的資料結構：
|
|
pcap_dispatch() 簡單的呼叫捕獲控制代碼 pcap_t 中定義的特定作業系統的讀資料函式：return p->read_op(p, cnt, callback, user)。在 linux 系統下，對應的讀函式為 pcap_read_linux()（在建立捕獲控制代碼時已定義 [pcap-linux.c]），而pcap_read_linux() 則是直接呼叫 pcap_read_packet()([pcap-linux.c])。
pcap_read_packet() 的中心任務是利用了 recvfrom() 從已建立的 socket 上讀資料包資料，但是考慮到 socket 可能為前面討論到的三種方式中的某一種，因此對資料緩衝區的結構有相應的處理，主要表現在加工模式下對偽鏈路層頭部的合成。具體程式碼分析如下：
|
|
資料包過濾機制
大量的網路監控程式目的不同，期望的資料包型別也不同，但絕大多數情況都都只需要所有資料包的一（小）部分。例如：對郵件系統進行監控可能只需要埠號為 25（smtp）和 110（pop3) 的TCP 資料包，對 DNS 系統進行監控就只需要埠號為 53 的 UDP 資料包。包過濾機制的引入就是為了解決上述問題，使用者程式只需簡單的設定一系列過濾條件，最終便能獲得滿足條件的資料包。包過濾操作可以在使用者空間執行，也可以在核心空間執行，但必須注意到資料包從核心空間拷貝到使用者空間的開銷很大，所以如果能在核心空間進行過濾，會極大的提高捕獲的效率。核心過濾的優勢在低速網路下表現不明顯，但在高速網路下是非常突出的。在理論研究和實際應用中，包捕獲和包過濾從語意上並沒有嚴格的區分，關鍵在於認識到捕獲資料包必然有過濾操作。基本上可以認為，包過濾機制在包捕獲機制中佔中心地位。
包過濾機制實際上是針對資料包的布林值操作函式，如果函式最終返回 true，則通過過濾，反之則被丟棄。形式上包過濾由一個或多個謂詞判斷的並操作（AND）和或操作（OR）構成，每一個謂詞判斷基本上對應了資料包的協議型別或某個特定值,例如：只需要 TCP 型別且埠為 110 的資料包或 ARP 型別的資料包。包過濾機制在具體的實現上與資料包的協議型別並無多少關係，它只是把資料包簡單的看成一個位元組陣列，而謂詞判斷會根據具體的協議對映到陣列特定位置的值。如判斷ARP型別資料包，只需要判斷陣列中第 13、14 個位元組（以太頭中的資料包型別）是否為 0X0806。從理論研究的意思上看，包過濾機制是一個數學問題，或者說是一個演算法問題，其中心任務是如何使用最少的判斷操作、最少的時間完成過濾處理，提高過濾效率。
BPF
Libpcap 重點使用 BPF（BSD Packet Filter）包過濾機制，BPF 於 1992 年被設計出來，其設計目的主要是解決當時已存在的過濾機制效率低下的問題。BPF的工作步驟如下：當一個數據包到達網路介面時，資料鏈路層的驅動會把它向系統的協議棧傳送。但如果 BPF 監聽介面，驅動首先呼叫 BPF。BPF 首先進行過濾操作，然後把資料包存放在過濾器相關的緩衝區中，最後裝置驅動再次獲得控制。注意到BPF是先對資料包過濾再緩衝，避免了類似 sun 的 NIT 過濾機制先緩衝每個資料包直到使用者讀資料時再過濾所造成的效率問題。參考資料D是關於 BPF 設計思想最重要的文獻。
BPF 的設計思想和當時的計算機硬體的發展有很大聯絡，相對老式的過濾方式CSPF（CMU/Stanford Packet Filter）它有兩大特點。1：基於暫存器的過濾機制，而不是早期記憶體堆疊過濾機制，2：直接使用獨立的、非共享的記憶體緩衝區。同時，BPF 在過濾演算法是也有很大進步，它使用無環控制流圖（CFG control flow graph）,而不是老式的布林表示式樹（boolean expression tree）。布林表示式樹理解上比較直觀，它的每一個葉子節點即是一個謂詞判斷，而非葉子節點則為 AND 操作或 OR操作。CSPF 有三個主要的缺點。1：過濾操作使用的棧在記憶體中被模擬，維護棧指標需要使用若干的加/減等操作，而記憶體操作是現代計算機架構的主要瓶頸。2：布林表示式樹造成了不需要的重複計算。3：不能分析資料包的變長頭部。BPF 使用的CFG 演算法實際上是一種特殊的狀態機，每一節點代表了一個謂詞判斷，而左右邊分別對應了判斷失敗和成功後的跳轉，跳轉後又是謂詞判斷，這樣反覆操作，直到到達成功或失敗的終點。CFG 演算法的優點在於把對資料包的分析資訊直接建立在圖中，從而不需要重複計算。直觀的看，CFG 是一種"快速的、一直向前"的演算法。
過濾程式碼的編譯
BPF 對 CFG 演算法的程式碼實現非常複雜，它使用偽機器方式。BPF 偽機器是一個輕量級的，高效的狀態機，對 BPF 過濾程式碼進行解釋處理。BPF 過濾程式碼形式為"opcode jt jf k"，分別代表了操作碼和定址方式、判斷正確的跳轉、判斷失敗的跳轉、操作使用的通用資料域。BPF 過濾程式碼從邏輯上看很類似於組合語言，但它實際上是機器語言，注意到上述 4 個域的資料型別都是 int 和 char 型。顯然，由使用者來寫過濾程式碼太過複雜，因此 libpcap 允許使用者書寫高層的、容易理解的過濾字串，然後將其編譯為BPF程式碼。
Libpcap 使用了 4 個源程式 gencode.c、optimize.c、grammar.c、scanner.c完成編譯操作，其中前兩個實現了對過濾字串的編譯和優化，後兩個主要是為編譯提供從協議相關過濾條件到協議無關(的字元陣列)位置資訊的對映，並且它們由詞彙分析器生成器 flex 和 bison 生成。參考資料 C 有對此兩個工具的講解。
|
|
編譯過濾字串呼叫了函式 pcap_compile()[getcode.c]，形式為：
|
|
其中 buf 指向使用者過濾字串，編譯後的 BPF 程式碼存在在結構 bpf_program中，標誌 optimize 指示是否對 BPF 程式碼進行優化。
|
|
過濾程式碼的安裝
前面我們曾經提到，在核心空間過濾資料包對整個捕獲機制的效率是至關重要的。早期使用 SOCK_PACKET 方式的 Linux 不支援核心過濾，因此過濾操作只能在使用者空間執行（請參閱函式pcap_read_packet() 程式碼）,在《UNIX 網路程式設計(第一卷)》（參考資料 B）的第 26 章中對此有明確的描述。不過現在看起來情況已經發生改變，linux 在 PF_PACKET 型別的 socket 上支援核心過濾。Linux 核心允許我們把一個名為 LPF(Linux Packet Filter) 的過濾器直接放到 PF_PACKET 型別 socket 的處理過程中，過濾器在網絡卡接收中斷執行後立即執行。LSF 基於 BPF 機制，但兩者在實現上有略微的不同。實際程式碼如下：
|
|
linux 在安裝和解除安裝過濾器時都使用了函式 setsockopt()，其中標誌SOL_SOCKET 代表了對 socket 進行設定，而 SO_ATTACH_FILTER 和 SO_DETACH_FILTER 則分別對應了安裝和解除安裝。下面是 linux 2.4.29 版本中的相關程式碼：
|
|
上面出現的 sk_attach_filter() 定義在 net/core/filter.c，它把結構sock_fprog 轉換為結構 sk_filter, 最後把此結構設定為 socket 的過濾器：sk->filter = fp。
其他程式碼
libpcap 還提供了其它若干函式，但基本上是提供輔助或擴充套件功能，重要性相對弱一點。我個人認為，函式 pcap_dump_open() 和 pcap_open_offline() 可能比較有用，使用它們能把線上的資料包寫入檔案並事後進行分析處理。
總結
1994 年 libpcap 的第一個版本被髮布，到現在已有 11 年的歷史，如今libpcap 被廣泛的應用在各種網路監控軟體中。Libpcap 最主要的優點在於平臺無關性，使用者程式幾乎不需做任何改動就可移植到其它 unix 平臺上；其次，libpcap也能適應各種過濾機制，特別對BPF的支援最好。分析它的原始碼，可以學習開發者優秀的設計思想和實現技巧，也能瞭解到（linux）作業系統的網路核心實現，對個人能力的提高有很大幫助。
B：《UNIX網路程式設計(第一卷)》 W.Richard Stevens
C：《使用 lex 和 yacc 編譯程式碼》 Peter Seebach
E：linux 聯機幫助手冊：socket(2)、socket(7)、packet等