Linux 內核是如何實現無線網絡接口呢?數據包是通過怎樣的方式被發送和接收呢?今天跟著 LinuxStory 小編一起來探索一番吧！

剛開始工作接觸 Linux 無線網絡時，我曾迷失在浩瀚的基礎代碼中，尋找具有介紹性的材料來回答如上面提到的那些高層次的問題。跟蹤探索了一段時間的源代碼后，我寫下了這篇總結，希望在 Linux 無線網絡的工作原理上，讀者能從這篇文章獲得一個具有幫助性的概覽。

1 全局概覽

在開始探索 Linux 無線具體細節之前，讓我們先來把握一下 Linux 無線子系統整體結構。如圖1,展示了 Linux 無線子系統各個模塊之間的抽象關系。 

圖一 Linux 無線網絡結構示意圖

圖示中的虛線內展示的是內核空間的情況。用戶空間的程序運行在最上層，而硬件相關的設備則在最下面。圖示中左邊為以太網設備，右邊為 WiFi 設備。

正如圖中看到的一樣，存在著兩種 WiFi 設備，具體是哪一類要看 IEEE802.11 標準的 MLME 如何實現。

如果直接通過硬件實現，那么設備就是硬 MAC (full MAC)設備;如果通過軟件的方式實現，那么設備就是軟 MAC (soft MAC)設備。現階段大部分無線設備都是軟件實現的軟 MAC 設備。

通常我們把 Linux 內核無線子系統看成兩大塊： cfg80211 和 mac80211 ，它們連通內核其他模塊和用戶空間的應用程序。

特別指出， cfg80211 在內核空間提供配置管理服務，內核與應用層通過 nl80211 實現配置管理接口。需要記住的是，

硬 MAC 設備和軟 MAC 設備都需要 cfg80211 才能工作。而 mac80211 只是一個驅動 API ，它只支持軟件實現的軟 MAC 設備。

接下來，我們主要關注軟 MAC 設備。

Linux 內核無線子系統統一各種 WiFi 設備，并處理 OSI 模型中***層的 MAC 、 PHY 兩層。

若進一步劃分， MAC 層可以分為 MAC 高層和 MAC 底層。前者負責管理 MAC 層無線網絡的探測發現、身份認證、關聯等;

后者實現 MAC 層如 ACK 等緊急操作。大部分情況下，硬件(如無線適配器)處理大部分的 PHY 層以及 MAC 底層操作。Linux 子系統實現大部分的 MAC 高層回調函數。

2 模塊間接口

從圖一中我們可以看出，各個模塊之間分界線很清晰，并且模塊間相互透明不可見。模塊之間一般不會相互影響。

舉個例子，我們在 WiFi 設備驅動做修改(如，打補丁、添加新的 WiFi 驅動等)，這些變更并不會影響到 mac80211 模塊，

所以我們根本不用改動 mac80211 的代碼。再如，添加一個新的網絡協議理論上是不用修改套接字層以及設備無關層代碼。一般情況下，內核通過一系列的函數指針實現各層之間相互透明。

如下代碼展示 rtl73usb 無線網卡驅動與 mac80211 的聯系。 

左側是 mac80211 為 WiFi 驅動模塊實現的 ieee80211_ops 結構體形式的回調接口，回調函數的具體內容由驅動層實現。

顯然，不同設備相應驅動的實現不同。結構體 ieee80211_ops 負責將不同設備驅動實現的回調函數與 mac80211 提供的 API 映射綁定起來。

當驅動模塊插入注冊時，這些回調函數就被注冊到 mac80211 里面(通過 ieee80211_alloc_hw 實現)，接著 mac80211 就綁定了相應的回調函數，根本不用知道具體的名字，以及實現細節等。

完整定義的 ieee80211_ops 結構包含很多成員，但不是所有都必須要驅動層實現。一般而言，實現的前七個成員函數就足夠了。但是，要想正確實現其他功能，某些相關的成員函數就需要被實現，就像上面的例子一樣。

3 數據路徑與管理路徑

圖一所示中，存在兩條主要路徑：數據路徑和管理路徑。數據路徑對應 IEEE802.11 數據幀，而管理路徑對應著控制幀。

在 IEEE802.11 的控制幀中，大部分用于如 ACK 這類時間緊急的操作，并且一般直接由硬件實現。一個例外可能就是 PS-Poll 幀(用于 Power Save 控制)，它也可以由 mac80211 實現。

數據和管理路徑在 mac80211 里面是分開實現的。

4 數據包是如何被發送?

接下來，我們集中探討下數據的發送過程。

首先，數據包起源于用戶空間的應用程序，應用程序首先創建一個套接字，然后綁定一個接口(如，以太網接口、 WiFi 接口)。

接下來將數據寫入到套接字緩沖區，***再將緩沖區的數據發送出去。在套接字創建時，我們需要指明將要使用的協議族，這將在內核中起作用。

剛才這些發生在圖一中的 Data Application 模塊中，最終應用程序陷入系統調用，隨后在內核空間進行接下來的工作。

數據的傳輸首先經過套接字層，這個過程中一個最重要的數據結構就是 sk_buff ，一般稱為 skb 。一個 skb 結構中的成員包含著緩沖區的地址以及數據長度。

它還為內核中不同層對數據的操縱提供了良好的支持;實現了眾多的接口，如，不同網絡層首部的插入與去除等。整個數據的發送/接收過程均會用到這個結構。

我們跳過網絡協議模塊，對于網絡協議我沒有太多想說的，因為一旦涉及網絡協議，簡直說不盡道不完。在這里協議并不是我們主要關心的。

不過我們需要知道的是，數據傳輸使用的協議在套接字創建的時候就與指定的協議綁定了，然后相關的協議便會負責相關層的數據傳輸。

接下來，數據由網絡層落到了設備無關層。這一層透明的連接著各種各樣的硬件設備(如以太網設備、 WiFi 設備等)。

設備無關層一個重要的結構是： net_device 。我們回去看圖一，再看接下來的代碼就能解釋內核是如何與以太網設備驅動通信的。

具體接口通過 net_device_ops 結構實現，該結構對應了 net_device 的很多操作。

如下是 net_device_ops 結構的部分成員：

發包的時候， skb 在調用 dev_queue_xmit 時被傳入。在跟蹤具體調用關系后，最終是這樣調用的： ops->ndo_start_xmit(skb, dev) 。

注意，剛才的這個函數需要注冊才能生效。

對于 WiFi 設備而言，通常我們使用 mac80211 (代替了相應的設備驅動)，那是因為 mac80211 已經幫我們注冊了。

從 net/mac80211/iface.c 可以看到：

因此 mac80211 也就可以看作是一個 net_device ，當一個數據包通過 WiFi 傳輸時，相關的傳輸函數 ieee80211_subif_start_xmit 將被調用。

我們進入 mac80211 內部 ieee80211_subif_start_xmit 實現可以看到這樣一個調用子序列：ieee80211_xmit => ieee80211_tx => ieee80211_tx_frags => drv_tx

目前我們處在 mac80211 和 WiFi 驅動的邊界， drv_tx 僅僅調用了一個在 WiFi 驅動層實現的并已注冊的回調函數。

到這里， mac80211 就結束了，并且設備驅動相關也暫時告一段落了。

正如之前提到的一樣，通過 mac80211 中的 local->ops->tx ，注冊到設備驅動中的回調函數將會被調用。盡管每個驅動對相應回調函數的實現不盡相同。

下面利用之前模塊間接口的例子。結構體成員 tx 對應的函數 rt2x00max_tx 首先需要填充準備發送描述符(一般包含幀長度、ACK 策略、 RTS/CTS、重傳時限、分片標志以及 MCS 等)

部分信息由 mac80211 傳下來(結構體 ieee80211_tx_info 中就有一些信息將會被使用到)，然后驅動程序還要將數據轉換成底層硬件可識別的形式。

一旦發送描述符就位，驅動程序還會調整幀數據(如，調整字節對齊等)，然后將數據幀放入發送隊列，***將要發送的幀的描述符發給硬件。

由于我們以一個基于 rt73usb 的 USB WiFi 適配器為例，所以數據幀***是通過 USB 接口發送給無線設備。

然后數據將被插入 PHY 首部以及其他信息，***數據包被發送到了空中。驅動同時也需要反饋發送狀態給 mac80211 ， 通常狀態信息存放在 struct ieee80211_tx_info 中。

經過 ieee80211_tx_status 一系列的調用，或者某些變種函數反饋給上層。

說到這里，關于數據包的發送也暫時告一段落了。

5 談談管理路徑

理論上，我們可以像數據路徑一樣在用戶空間下通過套接字發送控制幀。但是目前有很多開發得十分完善的用戶層管理工具能完成這樣的工作。

特別是 wpa_supplicant 和 host_apd 。wpa_supplicant 控制客戶端 STA 模式下無線網絡的連接，如掃描發現網絡、身份認證、關聯等。

而 host_apd 可以做 AP 。說白了前者就是用來連接熱點，后者用來發射熱點。這些用戶層工具通過 netlink 套接字與內核通信。

內核中相關的回調接口是 cfg80211 中的 nl80211 。用戶層的工具通過 netlink 提供的庫(如， NL80211_CMD_TRIGGER_SCAN )將命令發送到內核。

在內核中，由 nl80211 接收應用層發出的命令。如下代碼展示了對應綁定情況。

以 triggering scan 為例，掃描請求從 cfg80211 到 mac80211 是通過 mac80211 在 cfg80211 中注冊的回調函數來實現的。

在 mac80211 中， ieee80211_scan 將會具體去實現掃描發現網絡的具體細節。

6 數據包又是如何被接收?

我們接下來反過來看看數據接收的過程，現在我們不再比較數據路徑與管理路徑的不同了。相信讀者同樣能明白。

當一個數據包在空中被無線設備捕捉到后，硬件將會向內核發出一個中斷(大部分 PCI 接口的設備這樣做)，或則通過輪詢機制判斷是否有數據到來(如，使用了 USB 接口)。

前者，中斷將會引發中斷處理程序的執行，后者促使特定的接收函數將被調用。

一般設備驅動層的回調函數不會做太多關于接收數據包的操作，僅僅做數據校驗，為 mac80211 填充接收描述符，然后把數據包推給 mac80211 ， 由 mac80211 來做之后的工作(直接或間接將數據包放入接收隊列)。

數據進入 mac80211 后，將會調用 ieee80211_rx 或者其他變種接收函數。在這里數據路徑和管理路徑也將分開進行。

如果收到的幀是數據，它將被轉換成 802.3 數據幀(通過 __ieee80211_data_to8023 實現)，然后該數據幀將通過 netif_receive_skb 交付到網絡協議棧。在協議棧中，各層網絡協議將會對數據進行解析，識別協議首部。

如果接收到的是控制幀，數據將會由 ieee80211_sta_rx_queued_mgmt 處理。部分控制幀在 mac80211 層就終止，另外一些將會通過 cfg80211 發送到用戶空間下的管理程序。

例如，身份認證控制幀被 cfg80211_rx_mlme_mgmt 處理，然后通過 nl80211_send_rx_auth 發送到用戶空間下的 wpa_supplicant ; 相應的關聯響應控制幀被 cfg80211_rx_assoc_resp 處理，并由 nl80211_send_rx_assoc 發送到用戶空間。

7 總結一下

一般 WiFi 驅動包含如下三個部分：配置、發送回調、接收回調。再以 USB WiFi 適配器為例，當內核探測到設備被插入時，會調用 probe 函數。這可能發生在注冊配置好的 ieee80211_ops 時。

首先， ieee80211_alloc_hw 分配一個 ieee80211_hw 結構體，代表著相應 WiFi 設備。另外，如下的數據結構也會被分配：

wiphy 結構：主要用來描述 WiFi 硬件參數(如， MAC 地址、接口模式與組合、支持的波特率以及其他一些硬件功能)。

ieee80211_local 結構：這是一個設備驅動層可見的結構，并且被 mac80211 大量使用。ieee80211_ops 的映射綁定將鏈接到 ieee80211_local 中。 前者作為后者的一個成員。在 ieee80211_hw 中可以通過 container_of 或者 hw_to_local 這個專用 API 得到 ieee80211_local 。

設備驅動使用到的在 ieee80211_hw 中的私有結構 void *priv 。

注意：硬件設備的注冊由 ieee80211_register_hw 完成，前提是事先已經插入注冊了 mac80211 模塊，好比在 STA 模式中，要先用 wpa_supplicant 控制設備連接上了某個熱點才能進行通信一樣。

***希望這篇總結能讓相關人員在探索源代碼時具有整體把握。