IEEE 802.11 基礎架構網路故障診斷的架構與技術

原題：Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks

刊於第十屆行動運算與網路國際會議（MobiCom 2004）論文集。

翻譯說明：本文件依原 PDF 的閱讀順序翻譯全部正文、圖表標題與文字標籤、致謝、版權聲明及參考文獻題名。技術名稱、程式碼與書目識別資訊保留原文。圖形的曲線、長條與示意圖請對照原 PDF；本文不由圖形估算額外數值。「目前」「未來」等時間用語均指原論文撰寫時。

摘要

IEEE 802.11 無線網路的大規模部署，為企業的資訊科技（IT）部門帶來重大挑戰。使用者經常抱怨連線與效能問題，而網路管理員除了管理企業的安全與涵蓋範圍，也必須診斷這些問題。由於無線媒介本身不可靠，且缺乏可判定問題原因的智慧診斷工具，這項工作尤其困難。

本文提出一套用於偵測及診斷 IEEE 802.11 基礎架構無線網路故障的架構。據我們所知，本文是第一篇探討這類網路故障診斷問題的論文。作為架構的一部分，我們提出並評估一項稱為 Client Conduit 的新技術，讓失去連線的用戶端能完成初始設定並接受故障診斷。我們說明分析無線區域網路部署中效能問題的技術，也提出偵測未經授權存取點的方法。我們已在 Windows 作業系統上，使用市售 IEEE 802.11 網卡建立故障診斷架構的原型。初步結果顯示，這些機制有效，而且在用戶端沒有遇到問題時，產生的額外負擔很低。

分類與主題描述

C.2.3［電腦通訊網路］：網路運作。

一般術語

管理、可靠性。

關鍵字

基礎架構無線網路、故障偵測、故障診斷、失去連線的用戶端、IEEE 802.11、未經授權存取點（Rogue AP）。

1. 緒論

無線網路的便利性促成 IEEE 802.11 網路的廣泛採用 [22]。企業、大學、家庭與公共場所正以驚人的速度部署這些網路。然而，終端使用者與網路管理員仍面臨許多「痛點」。使用者會遇到連線時斷時續、效能不佳、缺乏涵蓋範圍及驗證失敗等問題。這些問題可能來自存取點配置不佳、裝置設定錯誤、硬體與軟體錯誤、無線媒介的特性（例如干擾與傳播），以及流量壅塞。

圖 1 顯示 Microsoft 公司資訊科技（IT）部門在六個月期間記錄的無線網路相關申訴數量。該公司大規模部署 IEEE 802.11 網路，在四十多棟建築中設置數千個存取點（Access Point，AP）。每件申訴都反映使用者的挫折，以及企業生產力的損失。此外，處理每件申訴都使 IT 部門增加支援人員成本；我們的研究發現，每件申訴的成本為數十美元，且尚未計入終端使用者生產力下降的損失。

為了迅速、有效地處理申訴，網路管理員需要能偵測、隔離、診斷及修正故障的工具。據我們所知，先前沒有研究處理 IEEE 802.11 基礎架構網路的故障診斷問題。相較之下，許多公司提供這方面的解決方案 [2, 4, 20, 16, 37]，顯示診斷這些問題在實務上的重要性。這些產品能相當妥善地呈現網路統計資料，但仍缺少一些理想功能。具體而言，它們未全面蒐集與分析資料，以判定問題的可能原因。此外，多數產品只從 AP 蒐集資料，忽略用戶端對網路的觀察。有些從用戶端角度監控網路的產品需要硬體感測器，而部署及維護這些感測器的成本可能很高。目前的解決方案也不支援失去連線的用戶端，儘管這些用戶端最需要協助。第 8 節將更詳細討論這些產品。

圖 1：某美國大型企業 IT 部門記錄的無線網路相關申訴數量。 橫軸：月份（1 至 6）；縱軸：無線網路相關問題數量。

本文提出一套具彈性的架構，用於偵測及診斷基礎架構無線網路的故障。我們在無線用戶端，以及在可行情況下的存取點，加入監測功能，觀察無線媒介與附近裝置。這套架構同時支援主動式與反應式故障診斷。我們以此監控框架處理部分困擾無線網路使用者的問題。

我們提出稱為 Client Conduit 的新技術，讓失去連線的用戶端藉由附近用戶端的協助診斷問題。這項技術利用 IEEE 802.11 的信標與探測機制，確保已連線用戶端不必為偵測失去連線的用戶端付出不必要的額外負擔。我們也提出尋找失去連線用戶端大致位置的簡單技術，以及利用附近無線用戶端診斷無線網路效能問題的技術。最後，我們說明這套監控架構如何自然地用於偵測企業無線網路中的 Rogue AP，也就是未經授權的存取點。

我們已在 Windows 作業系統上，使用市售 IEEE 802.11 網卡實作並評估基本架構框架、Client Conduit 與 Rogue AP 偵測；其他機制則使用 AiroPeek [38] 與 WinDump [39] 等工具評估。結果顯示，這些技術有效，而且在用戶端未遇到問題時，產生的額外負擔可忽略不計。

本文主要貢獻如下：

• 我們認為，本文是第一篇將 IEEE 802.11 基礎架構網路故障診斷指出為重要研究領域的論文。辨識這類環境中的各種問題是一項重要貢獻，因為無線故障診斷需要更多關注。
• 我們提出一套具彈性、以用戶端為基礎的架構，用於偵測與診斷 IEEE 802.11 基礎架構網路的故障。在無線網路情境中，這項方法具有獨特性，因為我們利用用戶端，以及在可行情況下的基礎架構 AP，監控網路與射頻（RF）環境。
• 我們說明一項簡單且有效率、稱為 Client Conduit 的技術，讓失去連線的用戶端透過附近其他已連線用戶端進行通訊；此機制可用於無線用戶端的初始設定，以及解決某些連線問題。
• 我們提出利用這套架構偵測與診斷多種故障的新方法，包括定位失去連線的用戶端、診斷效能問題，以及偵測 Rogue AP。

我們的工作只是朝向自我修復無線網路的第一步，仍有許多問題需要處理。在終端使用者與網路管理員每天遇到的大量無線問題中，我們只聚焦其中一部分；選擇依據是與網路管理員的交談 [11]，以及使用者申訴紀錄中觀察到的高優先級問題。雖然部分技術適用於其他部署情境，例如熱點與家庭，但我們主要著重企業無線網路的故障診斷。我們確保這些技術不會引入新的安全攻擊，但不以阻斷服務攻擊及貪婪的 MAC 攻擊 [31] 為研究焦點。

本文其餘內容安排如下：第 2 節討論使用者與網路管理員對無線區域網路部署最常抱怨的重要問題。第 3 節說明以用戶端為基礎之架構的元件。第 4 節介紹 Client Conduit 協定。第 5 節聚焦於定位失去連線的用戶端、隔離效能問題，以及偵測 Rogue AP。第 6 節說明系統實作，第 7 節評估各項技術。第 8 節討論相關研究。最後，第 9 節討論未來工作，第 10 節提出結論。

版權與複製聲明

允許免費製作本作品全部或部分的數位或紙本副本，供個人或課堂使用，前提是副本不得為營利或商業利益而製作或散布，且副本首頁須附上本聲明與完整引用資訊。以其他方式複製、重新出版、張貼於伺服器，或重新散布至郵件清單，須事先取得特定許可及／或支付費用。

MobiCom ’04，2004 年 9 月 26 日至 10 月 1 日，美國賓夕法尼亞州費城。版權所有 © 2004 ACM，1-58113-868-7/04/0009……5.00 美元。

2. 無線網路中的故障

我們列出使用者與網路管理員在使用及維護企業無線網路時，面臨的最重要問題。這份清單來自我們與 Microsoft IT 部門網路管理員及維運工程師的訪談與討論。這些人負責管理公司四十棟建築內、超過 4,400 個 IEEE 802.11 AP。

連線問題： 終端使用者抱怨建築內某些區域的網路連線不穩定或完全無法連線。這類「死角」（dead spots）或「射頻涵蓋缺口」（RF holes）可能由 RF 訊號微弱、沒有訊號、環境條件變動或障礙物造成。自動找出 RF hole 對無線網路管理員十分重要；接著可透過移動 AP、提高問題區域的 AP 密度，或調整附近 AP 的功率設定以改善涵蓋範圍，解決問題。

效能問題： 這類問題涵蓋所有用戶端觀察到效能下降的情況，例如吞吐量低或延遲高。造成問題的原因可能很多，例如壅塞導致流量變慢、微波爐或無線電話造成 RF 干擾、多路徑干擾、網路規劃不佳造成嚴重同頻道干擾，或用戶端／AP 設定不佳。效能問題也可能出現在網路的非無線部分，例如伺服器或 Proxy 速度慢。因此，診斷工具必須能判定問題發生在無線網路還是其他地方。此外，找出無線部分的原因，能協助管理員更妥善配置系統並改善終端使用者體驗。

網路安全： 大型企業經常使用 IEEE 802.1x [21] 等方案保護網路。然而，當員工在不知情的情況下，將未經授權 AP 接上企業網路的乙太網路接點，破壞網路安全時，就會形成 IT 管理人員的夢魘。這通常稱為「Rogue AP 問題」[4, 2, 15]。這些 AP 是無線網路安全最常見、最嚴重的漏洞之一。它們讓外部使用者能存取企業網路資源，進而洩漏資訊或造成其他損害。此外，Rogue AP 也可能干擾附近其他存取點。在大型網路中，人工偵測 Rogue AP 既昂貴又耗時，因此主動偵測十分重要。

驗證問題： 根據 IT 支援團隊的紀錄，許多申訴與使用者無法通過網路驗證有關。在以 IEEE 802.1x [21] 等技術保護的無線網路中，驗證失敗通常是因為憑證遺失或過期。因此，偵測這類驗證問題，並協助用戶端使用有效憑證完成初始設定，十分重要。

本文聚焦於偵測 RF hole、診斷效能問題、偵測 Rogue AP，以及透過 Client Conduit 協助用戶端從驗證問題中恢復。未來工作也將研究驗證問題的診斷。

3. 系統架構

以下說明組成故障偵測與診斷架構的元件。

3.1 系統需求

在說明系統元件之前，先列出系統需求：

• 用戶端軟體必須增加監控功能。在我們的系統中，修改 AP 軟體僅是為了提高可擴展性，以及分析 AP 效能（第 5.2 節）。由於不需要修改硬體，部署系統的門檻較低。
• 部分機制需要能控制信標（beacon）與探測（probe）。我們也要求用戶端能自行建立基礎架構網路，也就是成為 AP，或建立 ad hoc 網路；許多無線網卡支援這項能力，例如 Atheros [6]、Native WiFi [26]。若能選擇建立 ad hoc 或基礎架構網路，我們偏好後者，因為當時的網卡對基礎架構模式支援較佳。
• 我們仰賴記錄所有存取點位置的資料庫；這類位置資料庫通常由網路管理員維護。
• 部分技術要求附近存在其他用戶端或存取點。隨著 AP 部署增加，以及企業無線網路中無線筆電與 PDA 的使用普及，這項需求愈來愈容易滿足。事實上，根據兩天內從 AP 蒐集的 SNMP 資料，我們觀察到，在日間工作時段，所在樓層（約 2,500 平方公尺）有 13 至 15 個已關聯的無線用戶端；以這樣的密度，需求很可能得到滿足。

相較於必須在整個企業部署特殊無線感測器的現有產品，我們利用附近加入軟體「感測器」的用戶端與存取點，因此部署成本較低。

3.2 系統元件

系統包含下列元件：在無線用戶端機器上執行的診斷用戶端（Diagnostic Client，DC）、可選用且在存取點上執行的診斷 AP（Diagnostic AP，DAP），以及在組織後端伺服器上執行的診斷伺服器（Diagnostic Server，DS）；見圖 2。以下逐一說明。

診斷用戶端模組（DC）： DC 監控 RF 環境，以及鄰近用戶端和 AP 的流量。正常運作時，用戶端的無線網卡不會設為混雜模式（promiscuous mode）。DC 利用蒐集到的資料進行本地故障診斷。依個別故障偵測機制的需求，資料摘要會定期傳送給 DAP 或 DS。例如，為偵測 Rogue AP，原型中的 DC 每 30 秒傳送附近 AP 的 MAC 與頻道資訊。

DC 也能接受 DAP 或 DS 的命令，依需求蒐集資料，例如切換至混雜模式並分析附近用戶端的效能問題。若無線用戶端失去連線，DC 會將資料記錄到本地資料庫或檔案。未來恢復網路連線時，DAP 或 DS 可分析這些資料。

診斷存取點模組（DAP）： DAP 的主要功能是接受 DC 的診斷訊息，合併自身量測結果，並向 DS 傳送摘要報告。DAP 並非架構的必要元件，主要用於分擔 DS 的工作。多數技術可在傳統 AP 與 DAP 混合的環境中運作：若 AP 是傳統 AP，其監控功能由 DC 執行，摘要及檢查功能則由 DS 執行。為便於說明，本文其餘部分假設存在 DAP。

診斷伺服器模組（DS）： DS 接受 DC 與 DAP 的資料，進行適當分析以偵測及診斷不同故障。DS 也能存取儲存各 AP 位置的資料庫。網路管理員可部署多個 DS 平衡負載，例如將各 AP 的 MAC 位址雜湊至某個特定 DS。本文其餘部分以系統中只有一個診斷伺服器的方式說明。

圖 2 呈現故障診斷系統的示意圖。診斷伺服器會與其他網路伺服器互動，例如 RADIUS [32] 與 Kerberos [27] 伺服器，以取得用戶端授權與使用者資訊。本架構允許失去連線的用戶端透過附近已連線用戶端，以 Client Conduit 協定和 DS 通訊；第 4 節介紹此機制。

圖 2：故障診斷架構。 圖中標示：使用者層級資訊、驗證資訊、診斷伺服器（DS）、RADIUS、Kerberos、DHCP、診斷訊息／動作、傳統 AP、DAP、DC、傳送監控資訊、轉送失去連線用戶端的訊息、涵蓋區域、Client Conduit、失去連線的對等節點、診斷資訊流與有線連接。

系統同時支援反應式與主動式監控。在主動式監控中，DC 與 DAP 持續監控系統；若 DC、DAP 或 DS 偵測到異常，便發出警報供網路管理員調查。反應式監控則用於支援人員要診斷使用者申訴時。支援人員可從其中一個 DS 向 DC 發出指令，蒐集與分析資料以診斷問題。我們認為，反應式監控時，DC、DAP 與 DS 的網路及 CPU 負載小幅增加是可接受的；但在主動式監控中，這些額外負擔必須保持低度。

架構本身對電源管理造成的額外負擔可忽略不計；個別技術必須設計成避免不必要的電池耗電。本文稍後介紹的主動式與反應式技術耗用的頻寬、CPU 或磁碟資源都很少，因此對電池消耗的影響應可忽略。只有在 Client Conduit 資料傳輸期間，已連線用戶端才會替失去連線的用戶端收送訊息。為確保協助者的應用程式或電池不受明顯影響，系統提供可調設定，控制它願意投入此傳輸的資源量（見第 4.2.1 節）。

表 1 列出本文診斷的各種問題、參與診斷的實體（DC、DAP 與 DS），以及是否可使用傳統 AP。

表 1：不同故障診斷機制及可執行診斷的實體；最後一欄表示是否支援傳統 AP。

3.3 系統擴展

我們將系統設計成能隨用戶端與 AP 數量擴展。系統中兩種共用資源是 DS 與 DAP。為避免單一診斷伺服器成為潛在瓶頸，設計允許隨負載增加而加入更多 DS。此外，我們讓 DC 與 DAP 分擔診斷工作，降低各 DS 的負擔。只有當 DC 與 DAP 無法診斷問題，而且分析需要全域觀點與額外資料時，才使用 DS。例如，定位失去連線的用戶端可能需要多個 DAP 提供的訊號強度資訊。如前所述，存在傳統 AP 會降低可擴展性，因為通常由 DAP 執行的工作必須改由 DS 執行。

同樣地，由於 DAP 是共用資源，要求它執行額外工作，可能損害所有已關聯用戶端的效能。為降低 DAP 負載，各故障診斷機制可採用簡單的「忙碌 AP 最佳化」（Busy AP Optimization）：只要 AP 有任何已關聯用戶端，AP 就不執行主動掃描；這些操作由已關聯用戶端按需執行，例如 Rogue AP 偵測就需要這類掃描。AP 仍持續執行對效能影響可忽略的被動監控活動。若沒有任何用戶端關聯，AP 處於閒置狀態，便可執行這些監控操作。如此可在不損害 AP 效能的情況下，監控 AP 周圍大部分實體區域。

3.4 系統安全

DC、DAP 與 DS 之間的互動，使用透過 IEEE 802.1x 核發的 EAP-TLS [1] 憑證保護。授權的憑證機構（CA）向 DC、DAP 與 DS 核發憑證；我們利用這些憑證，確保各實體之間所有通訊都經過雙向驗證。

我們不處理環境中合法使用者的惡意行為。研究人員已針對熱點環境開發偵測貪婪及惡意行為的技術 [31]；其他研究也提出處理惡意用戶端向 DS 等中央實體傳送不實資訊的方法 [30]。這些方法與本設計互補，可納入系統。

4. Client Conduit

本節介紹稱為 Client Conduit 的新機制，讓失去連線的無線用戶端能向網路管理員及支援人員傳遞資訊。

若無線用戶端無法連上網路，DC 會將問題記錄於資料庫。當用戶端日後恢復連線，例如透過有線連線，便將紀錄上傳給 DS，由 DS 診斷問題原因。不過，有時這個用戶端可能位於其他已連線用戶端的通訊範圍內，只是剛好在所有 AP 的範圍之外，或因驗證問題而失去連線。在這種情況下，理想做法是立即透過 DS 診斷，並盡可能修正問題。以下聚焦這個情境。

乍看之下，可能會問：為何不讓失去連線的節點直接傳訊息給已連線鄰居？可惜這不可行，因為 IEEE 802.11 不允許用戶端同時連上兩個網路。已連線節點既已關聯至基礎架構網路，就無法同時與失去連線的用戶端 D 連上 ad hoc 網路。若想接收 D 的訊息，必須先斷線，再加入 D 建立的 ad hoc 網路。這對正常運作的已連線用戶端既沒效率，也不公平。

可能的解法包括在已連線用戶端使用多個無線電介面，其中一個專用於診斷的 ad hoc 網路；使用 MultiNet [14]，將單一無線網卡多工化，使其出現在多個網路中；或讓已連線用戶端定期掃描所有頻道。然而，這些方法都有不理想的特性：為了處理預期不常發生的問題，正常情況下的操作或成本也受到影響。定期掃描時，在不同頻道或網路間切換網卡，可能使已連線用戶端丟失封包。使用 MultiNet 時，網卡會定期花時間停留在 ad hoc 網路，耗用已連線用戶端的頻寬。相較之下，附近沒有失去連線的用戶端時，Client Conduit 不會帶來額外負擔。

4.1 Client Conduit 協定

以下說明 Client Conduit 協定，讓失去連線的用戶端透過其中一個已連線用戶端，接受 DS 診斷。Client Conduit 利用 IEEE 802.11 的兩項運作事實達成效率，避免對已連線用戶端造成負擔。第一，即使用戶端已關聯至 AP，仍會定期接收鄰近 AP 或 ad hoc 網路的信標。第二，已連線用戶端不必與基礎架構網路斷線，就能傳送定向或廣播 Probe Request。

以下以失去連線的用戶端 D 位於已連線用戶端 C 附近的情境說明（見圖 3）。前四步稱為「連線建立」（Connection Setup）階段，最後一步稱為「資料傳輸」（Data Transfer）階段。

1. D 上的 DC 將機器設為混雜模式，掃描所有頻道，以判定附近是否有用戶端已連上基礎架構網路。若在某頻道偵測到已連線用戶端，就在偵測到該用戶端封包的頻道上，建立新的基礎架構或 ad hoc 網路。基於第 3.1 節的理由，以及為方便說明，我們假設 D 切換模式成為 AP，並建立基礎架構網路。注意：檢查 IEEE 802.11 資料訊框的 ToDS 與 FromDS 欄位 [22]，D 就能判定資料封包是否屬於基礎架構網路，以及是否由 AP 傳出或傳向 AP。
2. D 上新形成的 AP 像一般 AP 一樣廣播信標，SSID 格式為 SOS_HELP_<num>，其中 num 是 32 位元隨機數，用來區分多個失去連線的用戶端。
3. C 上的 DC 偵測到這個新 AP 的 SOS 信標。此時，C 必須通知 D：已收到求助，可以停止廣播信標。若 C 嘗試連上 D，便需要斷開基礎架構網路，損害 C 的應用程式效能。因此，我們利用 IEEE 802.11 的「主動掃描」機制，讓 C 向 D 傳送格式為 SOS_ACK_<num> 的 Probe Request。這個 Probe Request 使用的 SSID 與 D 上 AP 宣告的 SSID 不同，因此可避免附近未參與 Client Conduit 的用戶端，在例行偵測環境中新 AP 時，意外向 D 發出相同的求助確認請求。
4. D 收到這個 Probe Request，也可能收到其他請求後，停止扮演 AP，重新成為工作站（station）。D 會針對 Probe Request 傳送 Probe Response，因此 C 知道不必繼續傳送 Probe Request；即使沒有回應，D 停止信標後，C 原本也會停止。更重要的是，D 的 Probe Response 會表示是否願意將 C 當成一個跳點，與 DS 交換診斷訊息。此回應機制確保多個已連線用戶端嘗試協助 D 時，D 只選其中一個建立通往 DS 的通道。
5. D 建立 ad hoc 網路，C 則透過 MultiNet [14] 加入。此時 C 成為 D 訊息的通道，D 能經由 C 與 DS 交換診斷訊息。

圖 3：Client Conduit 機制。 步驟 1 至 5 如上述說明。圖中節點：失去連線的用戶端 D、已連線用戶端 C、AP 與 DS。

此協定的主要優點，是已連線用戶端在正常運作時不承擔不必要的額外負擔。執行協定時的負擔將在本節稍後討論。

值得注意的是，Client Conduit 也可用於用戶端的初始設定。例如，用戶端首次嘗試存取無線網路，沒有 EAP-TLS 憑證，但持有 Kerberos 等其他認證資料時，可透過 Client Conduit 與後端 RADIUS／Kerberos 伺服器驗證使用者或機器，再於用戶端安裝新憑證。同樣地，過期憑證也能在不需要有線連線的情況下更新。

D 也可能位於 AP 範圍內，但因 IEEE 802.1x 驗證問題而失去連線 [11]。若範圍內也有已連線用戶端，便可使用 Client Conduit。若沒有，可動態設定 AP，允許 D 的診斷訊息經由未受控埠（uncontrolled port）[21] 傳送至後端 DS，或傳給能轉送至 DS 的 RADIUS 伺服器。

4.2 Client Conduit 的安全與攻擊

我們必須確保 Client Conduit 不會在系統中引入新的安全漏洞，或提供新的阻斷服務攻擊機會。為防止惡意或未經授權用戶端任意存取網路，已連線用戶端只允許失去連線用戶端的封包與 DS 或後端驗證伺服器交換。

以下討論兩種可能的濫用：損害提供協助的用戶端效能，以及將 Rogue AP 偽裝成失去連線的用戶端。

4.2.1 協助用戶端的效能下降

當已連線用戶端 C 透過 Client Conduit 協助失去連線用戶端時，必須確保 C 的應用程式效能不會受到不利影響。在連線建立階段，C 只需處理信標，以及收送探測訊息，不會替失去連線用戶端轉送任何訊息。這些步驟耗用 C 的資源可忽略，也不會造成 C 的安全資訊洩漏或安全受損。當然，若 C 發現失去連線用戶端頻繁要求執行這些步驟，也能進一步限制頻率或停止執行。

接著考慮資料傳輸階段可能的安全及阻斷服務攻擊。切換至 MultiNet 模式可能耗用已連線用戶端的頻寬 [14]，因此須處理兩個問題。第一，不能讓惡意用戶端透過不必要地迫使 C 進入 MultiNet 模式，浪費 C 的資源。第二，即使協助合法用戶端，C 也應能控制在 MultiNet 傳輸中願意分配給 D 的資源量。

第二個問題可透過可調設定解決，限制用戶端停留於 ad hoc 網路的時間相對於基礎架構網路的比例；C 也可為節省電池而限制使用量。第 7.2 節分析此取捨對失去連線用戶端造成的效能影響。

為防止惡意用戶端造成第一個問題，我們在資料傳輸前加入下列驗證步驟，確保只有合法用戶端可透過 C 連線。

連線建立階段之後，C 切換至 MultiNet 模式進行驗證。為避免攻擊者反覆迫使 C 進入 MultiNet 模式而形成 DoS 攻擊，C 可限制每分鐘執行驗證的次數。驗證時，C 取得失去連線用戶端的 EAP-TLS 機器憑證並驗證；為確保雙向驗證，D 也能執行同樣步驟。

若失去連線用戶端沒有憑證，或憑證已過期，C 可作為中介執行所需的驗證協定。例如 C 協助 D 與後端 Kerberos 伺服器進行 Kerberos 驗證並取得相關票證。若 D 仍無法通過驗證，C 會要求 D 傳送診斷紀錄最後一段，例如 10 KBytes，然後將紀錄轉送給 DS。

惡意用戶端可能反覆傳送這種未經驗證的紀錄，例如偽造不同 MAC 位址，以發動 DoS。為防止此事，已連線用戶端可限制固定期間內轉送的未經驗證資料總量，例如每五分鐘最多傳送 10 KBytes。

4.2.2 防止偽裝的 Rogue AP

如第 2 節所述，未經授權 AP 是企業無線網路的嚴重安全問題。攻擊者若想建立未經授權 AP 並保持不被偵測，可能利用 Client Conduit 的特性。攻擊者可讓 AP 使用 SOS SSID 廣播信標；Rogue AP 偵測機制（第 5.3 節）會假設這個裝置實際上是失去連線的用戶端，而不宣告其為 Rogue AP。因此，必須區分廣播信標的裝置究竟是合法用戶端，還是 Rogue AP。

在 Client Conduit 連線建立期間，失去連線用戶端成為 AP，或建立 ad hoc 網路並廣播信標時，不會收送任何資料封包。因此，只要 DC 偵測到某個 AP 或 ad hoc 節點一邊用 SOS SSID 廣播信標、一邊收送資料封包，就能立即標記為未經授權裝置。

還可使用另一項檢查：在 Client Conduit 第 4 步，協助用戶端收到 Probe Response 後，就知道失去連線用戶端不必繼續廣播信標。因此，若數秒後仍持續收到 SOS 信標，便可將裝置標記為偽裝的未經授權裝置。

5. 故障偵測與診斷

本節討論在 IEEE 802.11 無線網路中偵測及診斷故障的技術。第 5.1 節介紹定位失去連線用戶端的簡單方法；第 5.2 節介紹隔離效能問題的機制；第 5.3 節說明 Rogue AP 偵測。

5.1 定位失去連線的用戶端

在故障診斷系統中，自動定位失去連線的無線用戶端十分有用，可主動找出部署中的問題區域，例如涵蓋不佳或高干擾區域，也就是找出 RF hole，或定位可能故障的 AP。若失去連線用戶端聽不到任何 AP 信標，就能判定自己位於 RF hole，而非因驗證失敗等其他原因斷線。以下介紹「用於近似定位的雙重間接法」（Double Indirection for Approximating Location，DIAL），估計失去連線用戶端的位置，進而協助定位 RF hole。

如前所述，D 發現自己失去連線後，會成為 AP 或建立 ad hoc 網路，並開始廣播信標。附近已連線用戶端收到 D 的信標，記錄封包的訊號強度（RSSI），通知 DS：D 已失去連線，並傳送蒐集到的 RSSI 資料。

此時，DS 執行 DIAL 第一步，判定已連線用戶端的位置；可使用文獻中的任何已知定位技術 [8, 23]。下一步，DS 將這些已連線用戶端的位置作為「錨點」（anchor points），配合失去連線用戶端的 RSSI 資料，估計其大致位置。這一步可使用任何利用多個用戶端 RSSI 值定位機器的方法 [8, 12, 23]。

由於定位已連線用戶端本身存在誤差，再以這些錨點定位失去連線用戶端，會進一步增加誤差。第 7.3 節顯示，誤差約為 10 至 12 公尺，對估計失去連線用戶端的位置而言可接受。

5.2 網路效能問題

我們提出的效能診斷設計，由兩個輕量元件構成：主動式／被動監控元件，以及反應式診斷元件。監控元件在 DC 背景執行，偵測到效能不佳的連線時，通知診斷元件。接著診斷元件分析連線，輸出延遲分解報告，也就是有線與無線部分各自的延遲程度，並進一步將無線延遲分成用戶端、AP 及媒介的延遲。

監控元件在宣告遇到網路問題時，可以採取保守的判定方式；誤報只會啟動診斷元件。由於此元件的額外負擔低，啟動它對用戶端與 AP 效能的影響很小。這些元件尚未在目前的原型中實作，但我們已使用 AiroPeek、WinDump 等工具評估部分技術的有效性。

5.2.1 偵測網路效能問題

我們聚焦於 TCP 連線的效能診斷，因為 TCP 是網際網路上使用最廣泛的傳輸協定。對 TCP 連線，可利用資料封包與確認封包（ACK），被動診斷效能問題。其他傳輸協定則可透過主動探測或效能報告，例如 RTCP 報告 [33]，判定端到端遺失率與往返時間。

網路效能問題可表現為吞吐量低、遺失率高或延遲高。我們不使用吞吐量偵測問題，因為它取決於工作負載，即用戶端應用程式可能不需要高吞吐量，也取決於傳輸協定的特定參數，例如 TCP 初始視窗、傳送端與接收端視窗大小。我們改用封包遺失率與往返時間。

估計 TCP 連線的往返時間（RTT）很簡單：若用戶端是傳送端，本來就會追蹤 RTT；若是接收端，可使用 [40] 提出的啟發式方法估計 RTT。

遺失率則在用戶端使用 [18] 與 [5] 建議的啟發式方法估計。我們分別計算用戶端傳出與收到封包的遺失率。對傳出的資料封包，遺失率估計為最近 L 個 RTT 中，重傳封包數占傳送封包數的比例 [5]。

此估計假設 TCP 實作使用選擇性確認（Selective ACK），以避免不必要地高估遺失率。這項假設合理，因為 Windows、Linux、Solaris 等多個作業系統目前預設支援此選項。如 [5] 所示，TCP 發生逾時時，此估計可能高於實際遺失率。

對我們而言，這項誤差可接受，原因有二。第一，TCP 連線若持續逾時，可能確實有問題，值得診斷。第二，判定錯誤的唯一結果，是啟動額外負擔很低的診斷元件。若需要更精確分析，可使用 [5] 提出的 LEAST 方法。

對用戶端收到的資料封包，我們使用與 [18] 類似的方法估計遺失數：若收到封包的起始序號不是下一個預期序號，便將缺少的區段視為遺失。遺失率估計為最近 L 個 RTT 中，遺失封包數占預期封包總數的比例。

預期位元組數的計算，是以最近 L 個 RTT 中觀察到的最大序號減去最小序號；我們採用 [40] 的概念估計最大區段大小（MSS），再將位元組數除以 MSS，估計封包數。我們假設 TCP 連線很少以不按順序的方式交付區段；其他研究也觀察到這種情況 [10]。

若連線遺失情形嚴重或延遲高，偵測元件會啟動診斷元件。當特定封包的 RTT 超過 250 毫秒，或高於目前 TCP RTT 的兩倍時，便視為高延遲 [41]。為避免因短暫高延遲而啟動診斷演算法，只有當至少 D 個封包發生高延遲時，才標記這條連線。若傳送或接收封包的遺失率超過 5%，則將連線分類為高遺失率連線 [28, 41]。

D 與 L 都是可設定參數，各自代表偵測元件反應速度與不必要啟動診斷元件之間的取捨。D 或 L 小時，延遲或遺失率變化會迅速被偵測，但也可能不必要地啟動診斷。值較大時，除了反應較慢，也可能在蒐集足夠樣本前 TCP 連線就已結束，例如短時間的網頁傳輸。

可跨 TCP 連線彙整用戶端與遠端主機間的遺失率及延遲資訊，減輕此問題。目前我們正在探索這類技術，以及適當的 D、L 值。

5.2.2 隔離無線與有線問題

當用戶端 DC 偵測到 TCP 連線的網路效能問題，便與其關聯的 DAP 通訊，區分路徑中有線及無線部分的延遲。DAP 隨即開始監控該用戶端連線的 TCP 資料與 ACK 封包。

若 DC 是 TCP 傳送端，DAP 計算從用戶端送往遠端主機的資料封包接收時間，與對應 TCP ACK 接收時間之差；這個時間差就是有線網路延遲的估計。為確保 RTT 估計合理，這些往返量測也必須套用 TCP 的各種啟發式方法，例如 Karn 演算法 [34]。

DAP 將估計傳給 DC，DC 再從 TCP RTT 扣除它，得到無線部分延遲。當用戶端是接收端時，也能用類似方法分解：DAP 監控遠端主機送至用戶端的資料封包及對應 ACK，判定無線延遲。DAP 需維護的狀態量很小，只與尚未確認的 TCP 封包數相關；採樣還能進一步降低。

5.2.3 診斷無線網路問題

用戶端可能因許多原因而遇到無線效能不佳，例如 AP 或用戶端處理器過載、無線媒介問題，或 AP／用戶端的驅動程式及其他核心問題。我們觀察這些問題對無線網路路徑封包延遲的影響，量化其效果。

我們將效能問題分成三類：用戶端上的封包延遲、AP 上的封包延遲，以及無線媒介中的封包延遲。本節介紹稱為「利用旁聽鄰居估計延遲」（Estimating Delay using Eavesdropping Neighbors，EDEN）的協作方法，藉由其他用戶端量化上述各類延遲。由於電磁波以光速傳播，可安全地假設相較於用戶端或 AP 延遲，RF 傳播延遲可忽略。

當 D 的效能診斷元件被啟動，它會廣播封包，向附近用戶端尋求診斷協助。收到這些封包的所有用戶端會切換至混雜模式，並要求 DAP 開始診斷。第 7.1 節顯示，現代處理器進入混雜模式的 CPU 額外負擔很低。可使用與第 4.2 節類似的安全機制，防止針對這些用戶端的攻擊。

EDEN 使用多個旁聽用戶端，主要是為了提高穩健性：有多個用戶端時，至少一個能聽到以下 EDEN 請求及回應的機率會增加。

EDEN 分兩階段。第一階段，D 關聯的 DAP 估計 D 上的延遲。DAP 定期向 D 傳送 Snoop request，例如每兩秒一次。D 收到後立即回覆 Snoop response。旁聽用戶端記錄聽到 Snoop request 的時間，以及 D 首次嘗試傳送對應 Snoop response 的時間；也就是只記錄重傳位元未設定的回應封包。若旁聽用戶端漏掉任一封包，就忽略該請求／回應組的時間值。

兩個記錄時間的差，就是用戶端延遲，即 D 收到請求封包後經歷的應用程式及作業系統延遲。為提高穩健性，Snoop request 會重複傳送多次，例如 20 次；用戶端與 AP 延遲取這些量測的平均值。

第二階段以類似方法量測 AP 延遲：D 傳送 Snoop request，AP 回覆。D 也記錄這些請求／回應至 AP 的 RTT，以及未收到回應的請求封包數，例如因請求或回應遺失。

嚴格而言，這些用戶端及 AP 延遲，也包含無線媒介競爭造成的延遲。第 7.4 節討論流量壅塞為 EDEN 估計帶來的誤差程度。

協定結束時，所有旁聽用戶端將 AP 與用戶端延遲傳給 D。D 回報的 RTT 減去用戶端與 AP 延遲總和，可近似封包在正向與反向無線鏈路中的延遲總和。用戶端接著向網路管理員回報用戶端／AP／媒介的延遲分解，也能以未被確認的請求封包比例，作為無線鏈路網路層遺失率的指標。

5.3 Rogue AP 偵測

如第 2 節所述，Rogue AP 是接到企業或大學網路乙太網路接點的未經授權 AP；可能造成安全漏洞，以及不必要的 RF 與網路負載。Rogue AP 被視為企業無線區域網路的重要安全問題 [4, 2, 15]。

我們利用用戶端，以及在可行情況下的 AP，監控周遭環境的架構，很自然地適合偵測 Rogue AP。基本方法是讓用戶端與 DAP 蒐集附近 AP 的資訊，傳送給 DS。當 DS 收到 AP X 的資訊，便查詢 AP 位置資料庫，確認 X 是位於預期位置及頻道的已登錄 AP。

5.3.1 假設

我們假設所有 Rogue AP 與其連線的「未經授權」用戶端，都使用符合 IEEE 802.11 的市售硬體。本方法實質上提高了規避偵測的門檻，攻擊者必須使用經低階修改、不符合標準的 AP，才能突破方案：為避免偵測，攻擊者必須修改 Rogue AP，使其不廣播信標，也不回應 Probe Request。

當然，攻擊者可以直接使用專有存取點，或採用不同技術的存取點，例如 HIPERLAN。偵測這類入侵者需要特殊硬體，並非我們的目標。我們只希望用低成本機制處理當前部署中常見的 Rogue AP 問題。對許多網路管理員而言，主要目標是偵測員工為實驗或方便而意外安裝的 AP [11]。未來研究也將探索偵測不符合標準的 Rogue AP 與用戶端。

若兩家公司有相鄰無線網路，本機制會將另一家公司的 AP 分類為 Rogue AP。若此分類不可接受，雙方網路管理員可分享各自的 AP 位置資料庫。

5.3.2 用戶端與 AP 上的監控

每個 DC 在非混雜模式下監控附近封包。對偵測到的每個 AP，向 DS 傳送四元組 〈MAC 位址、SSID、頻道、RSSI〉。此四元組實質上識別特定位置及頻道上的 AP。要取得這些資訊，DC 必須判定周圍所有 AP 的 MAC 位址。

DC 可切換至混雜模式，觀察資料封包，利用封包中的 FromDS 與 ToDS 位元判定哪個位址屬於 AP。不過，也可用更簡單的方法達到相同效果：IEEE 802.11 要求所有 AP 定期廣播信標，DC 因此能從所有聽得到的 AP 信標取得 MAC 位址。第 7.5.1 節顯示，DC 不只會聽到自身頻道的信標，也可能聽到重疊頻道的信標；此特性提高 Rogue AP 被偵測的可能性。

為確保即使沒有用戶端位於與 AP 重疊的任何頻道，也不會漏掉 Rogue AP，我們使用 IEEE 802.11 的主動掃描機制。用戶端想知道附近有哪些 AP 時，逐一前往 802.11b 的 11 個頻道，傳送 Probe Request，並等待所有聽到請求的 AP 回覆 Probe Response；DC 可從回應取得 AP 的 MAC 位址。每個符合 IEEE 802.11 的 AP 都必須回應這類請求，而且部分晶片組 [26] 不提供停用此功能的控制選項。

依照整體框架，我們使用「忙碌 AP 最佳化」（第 3.3 節），讓 AP 只在沒有任何已關聯用戶端時，執行附近區域的主動掃描。

5.3.3 DS 上的分析

DS 從不同用戶端收到 AP 資訊後，以這些用戶端的位置及它們量得的 AP RSSI 值，利用 DIAL 估計 AP 的大致位置。

若四元組不符合 DS 的 AP 位置資料庫中某個已知合法 AP，就將其分類為 Rogue AP。也就是 MAC 位址不在資料庫中、AP 不在預期位置，或 SSID 不符合組織預期的 SSID。

若 AP 的 SSID 屬於 SOS SSID，DS 會略過後續分析，因為此 AP 實際上是正在執行 Client Conduit 連線建立階段的失去連線用戶端。

頻道資訊的用法略有不同。如前所述，特定頻道上的 AP 可能在重疊頻道被聽到。因此，只有回報頻道與其預期頻道不重疊，才因頻道判定為 Rogue AP。

若 AP 頻道改變，DAP 可要求 DS 更新 AP 位置資料庫。DAP 與 DS 之間通訊經過驗證；若 AP 是傳統 AP，則管理員可在修改頻道時更新位置資料庫。圖 4 彙整 DS 的檢查步驟。

圖 4：DS 判定 AP 是否為 Rogue AP 的決策步驟。 從「開始」依序檢查：MAC 是否已登錄？AP 是否位於預期位置？AP 是否位於預期頻道？AP 是否宣告預期 SSID？任一檢查結果為「否」，便偵測到 Rogue AP；全部為「是」，則通過檢查。

Rogue AP R 可能嘗試偽造 MAC 位址規避偵測，也就是以真正 AP G 的 MAC 位址傳送封包。但 DS 仍能偵測 R，因為 R 的位置或頻道會不同於 G；若位置與頻道相同，G 會立即偵測到它。

即使 Rogue AP 的信標不廣播 SSID，本方法仍可偵測，因為 DC 仍能從信標取得 MAC 位址。當然，也能用更簡單的方法：在企業區域網路中禁止不廣播 SSID 的 AP。

因此，在上述策略下，未經授權 AP 可能短暫不被偵測：它在現有 AP X 附近偽造 X 的身分、廣播組織中的有效 SSID，並停留在沒有 DC 或 AP 能旁聽其信標的頻道。但附近用戶端一旦執行主動掃描，就會偵測到 Rogue AP。如第 7.5.2 節所示，DC 很容易每五分鐘執行一次這種掃描。

6. 實作

以下說明故障診斷系統的實作細節。我們已實作由 DC、DAP 與 DS 背景服務構成的基本架構，但尚未實作驗證與紀錄機制。我們也已實作 Client Conduit 與 Rogue AP 偵測。DIAL 與 EDEN 支援目前正在加入。

系統在 Windows 作業系統上，使用 Netgear MA521 802.11b 網卡實作。DS 執行背景服務程序，接受 DAP 資訊。DS 從檔案讀取合法 AP 清單；從資料庫讀取的支援很容易加入。

DC 與 DAP 的程式碼由使用者層級背景服務及核心層級驅動程式構成（見圖 5）。只有當功能無法在使用者層級服務實現，或效能代價過高時，才將程式碼加入核心驅動程式。

核心驅動程式： 系統有兩個驅動程式：miniport 驅動程式，以及稱為 Native WiFi 驅動程式 [26] 的中介驅動程式（intermediate driver，IM driver）。

miniport 直接與硬體通訊，提供封包收送、設定頻道等基本功能。它公開足夠介面，讓關聯、驗證等功能可由 IM driver 處理。

IM driver 透過 ioctl 提供多個介面，查詢目前頻道、傳輸等級、電源管理模式及 SSID 等參數。除了設定參數，也允許使用者層級程式碼要求主動掃描、關聯至特定 SSID，以及擷取封包等。整體而言，它為使用者層級程式碼提供相當高的彈性與控制能力。

圖 5：DC 與 DAP 上的元件。 使用者模式：診斷背景服務。核心模式：TCP/IP、診斷 IM 模組、Native WiFi IM driver、診斷 miniport 模組、Native WiFi miniport driver；底層為 Native WiFi 網卡（NIC）。圖中亦標示 NDIS。

雖然大多數所需操作已存在於 IM driver，我們仍須修改它，以公開某些功能，並改善特定協定的效能。miniport 僅做少量修改，將某些封包類型公開給 IM driver。IM driver 加入的支援如下：

• 擷取封包標頭及封包： 允許設定篩選器，只擷取特定封包或標頭，例如依特定 MAC 位址、封包類型與子類型篩選，包括管理封包與信標。
• 儲存接收封包的 RSSI 值： 取得每個接收封包的 RSSI，並維護以 MAC 位址索引的 NeighborInfo 表，追蹤各鄰居的 RSSI。使用指數加權平均，新值的權重因子為 0.25。RSSI 用於以 DIAL 估計失去連線用戶端及 AP 的位置。
• 追蹤 AP 資訊： 在 NeighborInfo 表中，記錄從特定 MAC 位址收到封包的頻道、從信標取得的 SSID，以及裝置是 AP 還是工作站。這些資訊須送給 DAP／DS，以偵測 Rogue AP。
• 以核心事件提高協定效率： 加入核心與使用者層級程式碼共用的事件。發生「值得關注」的事件時，核心觸發它，使部分協定由輪詢改為中斷驅動。目前在 Client Conduit 中，只要核心聽到失去連線用戶端的 SOS 信標，就設定此事件，以降低協定延遲（第 7.2 節）。
• 加入多個 ioctl，以取得及清除上述資訊。

故障診斷背景服務： 此服務蒐集資訊並實作本文各種機制，例如蒐集 AP MAC 位址以偵測 Rogue AP，以及執行 Client Conduit。若裝置是 AP，便與 DS 及 DC 交換診斷資訊；若只是 DC，則與其關聯 AP 通訊，傳遞診斷資訊。

DC 上的診斷服務每 30 秒從核心取得目前的 NeighborInfo 表。若發現新節點，或既有資料明顯改變，例如用戶端 RSSI 值變動超過兩倍，便傳送給 DAP。DAP 也維護以 MAC 位址索引的類似表格，但只向 DS 傳送失去連線用戶端與 AP 的資訊；否則 DS 會收到系統中每個用戶端的更新，降低可擴展性。

DAP 定期向 DS 傳送新增或變更的 AP 資訊，目前原型的週期為 30 秒。此外，若 DAP 有尚待傳送的失去連線用戶端 D 資訊，就立即通知 DS，以便及時服務 D。

DC 到 DAP，以及 DAP 到 DS 的所有訊息，都採用 XML 格式。下列為 DC 訊息格式範例；時間戳記已省略：

<DiagPacket Type="RSSIInfo" TStamp="...">
  <Clients TStamp="...">
    <MacInfo MAC="00:40:96:27:dd:cc" RSSI="23"
      Channels="19" SSID="" TStamp="..."/>
  </Clients>
  <Real-APs TStamp="...">
    <MacInfo MAC="00:20:a6:4c:c7:85" RSSI="89"
      Channels="12" SSID="UNIV_LAN" TStamp="..."/>
    <MacInfo MAC="00:20:a6:4c:bb:ad" RSSI="7"
      Channels="10" SSID="EXPER" TStamp="..."/>
  </Real-APs>
  <Disconnected-Clients TStamp="...">
    <MacInfo MAC="00:40:96:33:34:3e" RSSI="57"
      Channels="2048" SSID="SOS_764" TStamp="..."/>
  </Disconnected-Clients>
</DiagPacket>

如範例所示，DC 傳送其他已連線用戶端、AP 與失去連線用戶端的資訊。每類實體的資訊包含機器 MAC 位址、RSSI、SSID，以及頻道位元圖，指出在哪些頻道旁聽到該裝置。

7. 系統評估

以下評估各機制，顯示它們不只有效，而且額外負擔低。基本架構、Client Conduit 與 Rogue AP 偵測以原型評估；DIAL 與 EDEN 的有效性則結合 AiroPeek [38]、WinDump [39] 等工具展示。

第 7.1 節介紹協定使用的個別操作耗時。第 7.2 節分解 Client Conduit 的成本，顯示它能及時協助失去連線的用戶端。第 7.3 節展示 DIAL 定位的有效性。第 7.4 節評估 EDEN 隔離效能問題的有效性。第 7.5 節顯示 Rogue AP 偵測的掃描需求對用戶端負擔很低。最後，第 7.6 節討論 Client Conduit、DIAL、EDEN 與 Rogue AP 偵測的可擴展性。

7.1 個別操作的成本

為了解偵測及診斷機制，例如 Client Conduit，各種操作的成本，我們執行一系列微型基準測試。我們認為這些數值對其他研究人員建立模型也有價值。結果見表 2。

機器從 AP 切換至工作站模式的成本不到兩秒，包括實際切換約 731 毫秒，以及硬體規格要求的數百毫秒等待。

表 2：不同操作的耗時。U 表示從使用者層級程式碼量測的時間；其餘為對應 ioctl 完成所需時間。

我們也進行實驗，了解將網卡設為混雜模式的額外負擔。首先使用 A、B、C、D 四台機器，判定混雜模式是否影響機器的輸入／輸出頻寬。A 以全速向 C 執行 TCP 傳輸，B 同時以全速向 D 傳輸。實驗進行三次，每次先讓 C 處於正常模式，再切至混雜模式。

觀察到 C 的吞吐量幾乎不受影響：正常模式下，輸入頻寬為 254.7 KB／秒，標準差 63.7 KB／秒；混雜模式下為 252.3 KB／秒，標準差 21.7 KB／秒。

另一項實驗判定混雜模式下的 CPU 使用率。A 與 B 之間執行全速 TCP 傳輸，期間先讓 M 處於正常模式，再切至混雜模式。圖 6 顯示 M 的 CPU 負擔；M 是 1 GHz Pentium III 機器。即使是這樣相對較舊的機器，混雜模式的 CPU 負擔仍低，大多低於 10%，且未觀察到封包丟失。因此，混雜模式造成的 CPU 額外負擔相當低。

圖 6：混雜模式下的 CPU 使用率（1 GHz 機器）。 橫軸：時間（秒）；縱軸：CPU 使用率；曲線：混雜模式、正常模式。

7.2 Client Conduit

為量測 Client Conduit 效能，實驗配置一個 AP、已連線用戶端 C，以及失去連線的用戶端 D。C 是 1 GHz Pentium III 機器，D 是 800 MHz Pentium III 機器。兩者皆有 512 MB 記憶體與 Netgear MA521 802.11b 網卡。

圖 7 顯示連線建立階段的總時間與各部分耗時。「使用者時間」表示使用者層級實作的端到端耗時；「核心時間」表示相同功能所需的 ioctl 耗時。兩者成本相近，支持我們只將必要機制放在核心、其餘大部分協定由使用者層級驅動的做法，後者也較容易除錯。

圖中前兩個長條的已連線用戶端背景服務與核心共用事件；偵測到失去連線用戶端的信標時，核心立即通知服務（第 6 節）。因此，失去連線用戶端只需短暫等待，就能收到 C 表示願意協助的 Probe Request，見「取得 ACK」時間。若服務定期從核心取得資訊，而非採中斷驅動，延遲會高很多。第三個長條顯示每十秒向核心輪詢一次資訊時的耗時分解；從失去連線用戶端角度看，「取得 ACK」的延遲較高。

圖 7：Client Conduit 的成本分解。 協定步驟依圖例由下而上執行，從「設定頻道」開始。步驟依序為：設定頻道、成為 AP、等待一秒、設定 SSID、設定信標週期、取得 ACK、成為工作站、等待一秒、ad hoc 模式關聯。三個長條：使用者時間（毫秒）、核心時間（毫秒）、採輪詢的使用者時間（毫秒）。縱軸：時間（毫秒）。

以下澄清兩項實驗細節。第一，初始設定頻道並檢查可用用戶端的步驟約需 190 毫秒。最差情況下，失去連線用戶端可能必須掃描全部頻道，檢查已連線用戶端；此時可能需兩至三秒。第二，設定 AP／工作站模式約需 730 毫秒，但硬體規格要求作業系統在新模式使用網卡前，再等待數百毫秒。為提高穩健性，我們在每次模式切換後加入一秒延遲；圖中包含這些延遲。

由圖可見，失去連線用戶端的連線建立及關聯耗時合理：建立階段不到五秒，另需 1.9 秒以 ad hoc 模式與 C 關聯，讓 C 能啟動 MultiNet。

MultiNet 在已連線用戶端啟動後，失去連線用戶端便能與 DS 互動，診斷問題，例如向 DS 傳送憑證或紀錄檔。為評估 MultiNet 傳輸時間，實驗讓 D 透過 C 向 DS 傳送不同大小的檔案：100 KB、500 KB 及 1 MB。

圖 8 顯示 C 允許 17% 至 50% 時間用於 ad hoc 模式時的傳輸耗時。C 在基礎架構網路停留 500 毫秒，ad hoc 網路停留時間則在 100 至 500 毫秒間變動。實驗中，從 ad hoc 切至基礎架構模式需 500 毫秒，反向切換需 300 毫秒。

如預期，檔案傳輸速度直接取決於已連線用戶端停留在 ad hoc 網路的時間。我們預期，隨較新網卡降低切換延遲負擔，傳輸速度將改善。

因此，結果顯示 Client Conduit 可讓失去連線用戶端的問題在數秒內回報，甚至可能解決，例如更新過期憑證。

圖 8：失去連線用戶端經由 MultiNet 傳輸資料所需時間。 橫軸：已連線節點提供的時間比例；縱軸：資料傳輸時間（秒）；曲線：1 MB、500 KB、100 KB。

7.3 位置判定

以下評估第 5.1 節 DIAL 方法定位失去連線用戶端或 Rogue AP 的準確度。不同於先前定位研究，DIAL 有額外誤差，因為參考點本身的位置可能不夠準確。

由於 RADAR [8] 簡單，我們使用它根據錨點定位失去連線用戶端，以評估 DIAL。若使用 [23] 等更精細的 RSSI 方法，還能進一步減少 DIAL 誤差。

實驗將三個已連線用戶端放在同棟建築同樓層的三間辦公室。我們取得樓層平面圖，套用 Cohen-Sutherland 線段裁剪演算法 [19]，計算各用戶端與其他房間之間的牆壁數。

我們將失去連線用戶端放在七個不同位置，讓它傳送廣播封包，以 AiroPeek [38] 量測已連線機器收到這些封包的 RSSI。再利用 [8] 的方程式計算牆壁衰減因子（WAF）。根據 WAF，若 X 位置的預測訊號強度最接近三個已連線用戶端的觀測值，便推定失去連線用戶端位於 X。

首先使用已連線用戶端的精確位置，在蒐集到的 RSSI 上執行 RADAR，定位 D。計算預測位置相對於實際位置的誤差；圖 9(a) 的「無誤差」（No Error）長條顯示此誤差。

接著再次執行演算法，假設其中一個已連線用戶端的位置估計偏差 3.3 公尺，也就是建築內房間的平均寬度。例如 A 實際在 X 房間，但在 RADAR 作為錨點時，估計位置被視為相鄰 Y 房間。圖 9(a) 第二個長條顯示此情況的誤差。其餘長條顯示一個、兩個或三個已連線用戶端的位置估計各偏差一間房間時，定位失去連線用戶端的誤差。圖 9(b) 則顯示偏差兩間房間距離時的誤差。

結果顯示，已連線用戶端的已知位置沒有誤差時，中位數定位誤差為 9.7 公尺。當一個或多個用戶端的估計位置偏離真實位置一間或兩間房間時，此中位數誤差最多增加到 12 公尺。

不過，若已連線用戶端的位置估計偏差兩間房間，最大誤差會明顯變高，例如三個用戶端位置皆錯誤時可達 33 公尺。這發生於不同用戶端的估計位置朝不同方向偏離，例如 A 向北偏、B 向南偏。

圖 9：定位失去連線用戶端的中位數誤差。 (a) 已連線用戶端估計位置偏離真實位置一間房間；(b) 偏離兩間房間。誤差棒下界與上界分別為最小、最大誤差。E(i) 表示第 i 個已連線用戶端的位置有誤差。橫軸情況：無誤差、E(1)、E(2)、E(1,2)、E(3)、E(1,3)、E(2,3)、E(1,2,3)；縱軸：中位數定位誤差（公尺）。

以 Cricket [29]、Active Badges [36] 等機制定位已連線用戶端，可將錨點誤差維持在低於一間房間。錨點位置準確時，DIAL 誤差將與最佳已知 RSSI 定位機制相近。

即使在使用 RADAR 的本實驗配置中，誤差為 10 至 12 公尺仍可接受，因為 DIAL 的目標只是找出失去連線用戶端或 Rogue AP 的大致位置。因此，結果顯示 DIAL 是協助管理員估計問題區域大致位置的實用方法。

7.4 估計無線延遲

第 5.2.3 節介紹 EDEN，利用附近用戶端量測無線工作站或 AP 的延遲。以下顯示 EDEN 能以合理準確度估計端點延遲。

EDEN 在附近用戶端量測 Snoop request 與 response 的時間，估計封包在用戶端或 AP 停留的時間。但量測也包含機器因媒介競爭而等待的延遲。

為了解此壅塞延遲程度，我們在同一頻道配置 A、B、C、D 四台機器。A 全速向 B 傳輸資料，在媒介中產生壅塞。接著將 C 關聯至執行 Native WiFi AP 的 D。Native WiFi AP 向已關聯用戶端傳送 20 個 ping 封包，用戶端回覆 ping reply。

實驗進行兩次：第一次不增加用戶端延遲；第二次在用戶端的 ping request 與 reply 之間額外加入 40 毫秒。透過第五台執行 AiroPeek 的機器，觀察到 EDEN 約高估用戶端延遲三毫秒。

當用戶端或 AP 是瓶頸時，這種誤差可能可接受。但若它們不是瓶頸、EDEN 分析的是低延遲情境，或競爭更嚴重，例如 802.11b 的競爭延遲甚至可能超過 20 毫秒，就需要更好的估計。目前我們正探索降低這類誤差的機制。

接著進行實驗，判定 EDEN 估計端點延遲的準確度。用戶端關聯至另一台扮演 AP 的機器，兩者皆使用 Netgear MA521 802.11b 網卡及對應 Native WiFi 驅動程式。我們在用戶端所有封包的路徑注入 30 至 300 毫秒延遲。

為模擬 EDEN，AP 向用戶端傳送 20 個 ping；ping 與回覆分別模擬 Snoop request 與 response。第三台執行 AiroPeek 的機器旁聽這些 ping，實際上模擬 EDEN 的旁聽用戶端。分析蒐集資料以估計用戶端延遲。圖 10 顯示，EDEN 的端點延遲估計相當準確，誤差低於實際注入延遲的 5%。

圖 10：EDEN 估計用戶端延遲的準確度。 橫軸：用戶端注入延遲（毫秒）；縱軸：延遲估計誤差（%）。

最後，研究 EDEN 將延遲分為用戶端、AP 及媒介的有效性。使用與前項實驗相似的三台機器配置；為估計 AP 延遲，用戶端也向 AP 傳送 ping。

我們增加用戶端與 AP 距離，以增加媒介延遲。相較於彼此靠近的情況，較遠距離導致更多重試，因此媒介延遲增加；距離增加也增加兩台機器之間的牆壁數，削弱接收訊號。

為提高準確度，實驗在預期無線流量較低的夜間進行。企業 LAN 日間被員工積極使用，我們不希望流量干擾影響量測。

圖 11 顯示三種情境的 EDEN 分解。「40-40-near」表示 AP 與用戶端放得很近，兩台機器的所有封包各增加 40 毫秒延遲。「40-40-far」相同，但 AP 與用戶端距離較遠。「0-0-far」則不在用戶端或 AP 注入延遲，只將它們放得較遠。

在 40-40-near 情境，EDEN 估計用戶端與 AP 延遲大致相等。隨距離增加，即 40-40-far 與 0-0-far，媒介延遲增加，EDEN 也能估計這項變化。後兩種情境中，用戶端與 AP 延遲也增加數毫秒，因為網卡為降低錯誤率，以較低的 1 Mbps 速率傳送封包。結果顯示，EDEN 能有效取得無線環境的延遲分解。

圖 11：EDEN 估計的用戶端、AP 及媒介延遲分解。 橫軸：40-40-near、40-40-far、0-0-far；縱軸：往返延遲（毫秒）；堆疊項目：用戶端延遲、AP 延遲、媒介延遲。

7.5 Rogue AP 偵測

本節探討兩項相關問題。第 7.5.1 節顯示重疊頻道有助於更快偵測躲在沒有 AP 或用戶端頻道上的 Rogue AP。第 7.5.2 節顯示，即使無法在重疊頻道旁聽到 Rogue AP，用戶端仍有充分機會在不損害效能下執行主動掃描。

為檢查實作有效性，我們在所在建築樓層執行 Rogue AP 偵測，成功找出所有「已知」Rogue AP；這些是同事使用的實驗 AP。

7.5.1 重疊頻道

已知 IEEE 802.11 重疊頻道不只會互相干擾，有時某頻道的網卡也能解碼另一重疊頻道的封包。這有助 Rogue AP 偵測：若用戶端在與 Rogue AP 頻道重疊的頻道上，且能聽到該 AP 信標，就能發現其存在。

為驗證重疊程度，實驗先將 AP 放在頻道 1，附近用戶端在全部 11 個頻道檢查其信標。接著將 AP 依序放在頻道 2 至 11，重複實驗，記錄在哪些頻道能聽到它。一次測試中，用戶端在每頻道停留一秒；另一次停留五秒。

圖 12 的橫軸為 AP 所在頻道，縱軸為能聽到 AP 的頻道。可見各頻道間的重疊不可忽略，而且有助偵測 Rogue AP。時間充分時，例如五秒測試，Rogue AP 的某些封包被監控 DC 接收到的可能性更高。

圖 12：能旁聽到 AP 的重疊頻道。 橫軸：AP 廣播信標的頻道；縱軸：可正確解碼信標的頻道；標記：一秒與五秒測試皆偵測到、只有五秒測試偵測到。

上述實驗中，AP 與用戶端相距五英尺，中間有一個障礙物。為研究距離增加時，重疊頻道間封包洩漏的變化，我們將 AP 機器放在樓層不同房間的十個位置，重複實驗。

圖 13 顯示，AP 與監控用戶端距離增加時，能聽到 AP 的頻道變少；由於障礙物影響，下降並非單調。

這些結果顯示，雖然不能將頻道重疊視為保證偵測 Rogue AP 的方法，它仍可減少頻繁主動掃描的需求。這也代表更多偵測機會：Rogue AP 若想不被偵測，就必須遠離所有位於重疊頻道的用戶端。

圖 13：隨距離變化能聽到的重疊頻道。 橫軸：距離（英尺）；縱軸：能感測 AP 信標的頻道數；曲線：頻道 1、4、7。

7.5.2 可用於主動掃描的閒置時間

如第 7.2 節所示，主動掃描可能需要約兩秒。目前實作每五分鐘執行一次主動掃描，稱為「主動掃描週期」（Active Scan Period）。雖然 300 秒中的兩秒占比很小，用戶端仍必須在適當時機掃描，否則可能干擾流量，例如送給用戶端的封包被丟棄，或 TCP 逾時。

理想上，掃描應在節點閒置且沒有進行網路傳輸時執行。為判定目前使用模式是否存在這種閒置時間，我們以 Ethereal [17] 蒐集三位同事桌上型電腦數日的流量軌跡。

雖然這些軌跡來自連接有線網路的桌機，仍能合理估計使用者產生的流量。當使用者開始以筆電作為主要機器，網路與閒置行為很可能類似桌機。

我們將軌跡分成五分鐘區段，也就是主動掃描週期，找出每區段最長的網路閒置時間。圖 14 呈現一天 24 小時內，每個五分鐘區段的最大閒置時間。圖中每點，例如中午 12:00 至 12:05，是對多日、多台機器相同時段的最大閒置時間取平均。

圖中顯示有大段閒置時間可供主動掃描：五分鐘區段中，可用的最小閒置期間為 118 秒，通常很容易找到超過 2.5 至 3 分鐘的閒置期間。因此，Rogue AP 偵測方案每五分鐘主動掃描，都有很大的機會窗口。

既有這些機會，可用任何啟發式方法預測閒置時間，啟動需兩秒的掃描。我們研究一個簡單、基於歷史的方法：若網路已閒置 X 秒，預測接下來兩秒也會閒置。因此，每過五分鐘，只要偵測模組觀察到網路介面已閒置 X 秒，就執行主動掃描。

我們對三台機器的軌跡，分別以 X 為五秒及十秒評估。兩種設定中，超過 95% 情況下，掃描都能在閒置期間完成。這個簡單方法的有效性顯示，無線用戶端很容易在不損害效能下，執行 Rogue AP 偵測所需的主動掃描。

圖 14：一天中不同時段，每五分鐘區段可用的最大閒置時間。 橫軸：一天中的時間（小時）；縱軸：每五分鐘內的最大閒置期間（秒）。

7.6 可擴展性分析

如第 3.3 節所述，架構設計成可隨 AP 與用戶端數量擴展。以下討論主動式與反應式技術為何維持這項特性，也說明即使某區域多個用戶端同時遇到無線問題，反應式機制仍只產生低度網路負擔。

如第 6 節所述，各 DC 每 30 秒主動向 DAP 傳送附近裝置的 RSSI、SSID 與 MAC 資訊，供 Rogue AP 偵測。DAP 篩選資料，每 30 秒傳送 AP 資訊。

為了解無線鏈路耗用頻寬，我們以單一 DC、DAP 與 DS 執行四小時實驗。觀察到 DC 頻寬消耗低於 0.2 Kbps，DAP 需求低於 0.01 Kbps。即使有大量用戶端，頻寬使用仍低，例如 100 個 DC 約 20 Kbps。因此，主動式監控的頻寬需求可忽略。

接著分析反應式診斷，也就是 Client Conduit 與 EDEN 的頻寬負擔。不另討論 DIAL，因其信標屬於 Client Conduit，向 DAP 傳送 RSSI 的負擔也已討論。

EDEN 與 Client Conduit 連線建立階段，也就是信標及探測訊息，頻寬需求很低，因為只以低頻率傳送小型廣播或信標封包。例如 Client Conduit 每 100 毫秒一次，EDEN 每兩秒一次。MultiNet 期間的頻寬也可控制：如第 4.2 節所述，已連線用戶端可限制分配給失去連線用戶端的頻寬。因此，若只有一個用戶端需要協助，反應式機制負擔很小。

以下分析某區域大量用戶端，例如 50 個，同時遇到故障並使用反應式診斷的情況。為確保網路效能不惡化，基本做法是限制機制速率；目前原型尚未實作這些協定擴充。

在 Client Conduit 中，若失去連線用戶端聽到 N 個失去連線用戶端的信標，就不使用固定 100 毫秒信標週期，而每 K 毫秒傳送一次，其中 K 是 0 到 100 × N 毫秒之間的隨機數。這種自我調節可確保某區域突然失去涵蓋時，網路不會被 Client Conduit 信標淹沒。

EDEN 也使用類似自我調節機制，限制初始廣播封包速率。此外，為限制已連線用戶端 C 的負擔，也可能降低反應式方案對 DAP 與 DS 的負載，可採取 C 任一時刻只協助一個用戶端的策略。因此，即使大量用戶端遇到問題，這些策略也能確保 Client Conduit 與 EDEN 的頻寬負擔維持低度。

8. 相關研究

據我們所知，先前沒有 IEEE 802.11 基礎架構網路故障診斷的研究。不過，有多種商業產品對網路管理工作提供不同程度的支援，例如 AirWave [4]、Network Systems and Management（NSM）[16]、Wireless Security Advisor [20]、AirDefense [2]、SpectraMon／SpectraGuard [37]、AirMagnet [3] 與 Symbol [35]。由於這些產品是專有產品，可取得的說明通常描述功能集合，而非所用技術；以下比較建立在我們對其產品型錄的理解。

多數產品較著重無線網路管理。這些工具讓管理員取得並視覺化 AP 資料、升級韌體、管理安全政策等。有些也利用 IEEE 802.11 統計，例如封包吞吐量、重試次數及 AP 丟棄封包數，提供即時 WLAN 效能監控。

這些低階統計對管理員有用，但更理想的是提供高階故障偵測與診斷。例如本方法能偵測網路效能問題，並指出有問題的元件。

許多產品，例如 AirWave 與 Unicenter，只在 AP 或伺服器端運作，沒有在用戶端加入監測功能。考量無線媒介的不對稱性與變動性，用戶端資料對診斷十分重要。例如用戶端附近的干擾可能與 AP 附近截然不同，詳細效能分解需要用戶端資訊。

此外，修改用戶端的做法能讓我們透過 Client Conduit 協助失去連線用戶端、定位 Rogue AP 與失去連線用戶端，並提高 Rogue AP 偵測涵蓋範圍。

AirMagnet、AirDefense 等產品在組織各處部署專用感測器，以取得完整企業視野；感測器將所有封包送往伺服器分析。與多位管理員交談取得的經驗性資訊顯示，感測器監控產品部署昂貴，且即使只有少數感測器，也會因網路流量造成明顯效能下降。

我們使用一般無線用戶端，避免額外硬體部署成本。當然，限制是部分故障診斷仰賴附近存在用戶端；但組織中無線用戶端日益普及，使這項需求更容易滿足。

由於 Rogue AP 是嚴重安全問題，上述產品皆執行 Rogue AP 偵測。與本方案不同，多數使用其他 AP [4, 16] 或專用感測器 [2, 3, 37] 達成；如前所述，這些方法存在部署及故障偵測限制。

我們同時使用用戶端與 AP 偵測 Rogue AP，類似 Symbol 的方法 [35]。但本方法也能偵測偽造真正 AP MAC 位址的 Rogue AP；此外，利用用戶端及 AP 的監測功能，還能透過 DIAL 估計 Rogue AP 位置。

上述產品均未提供協助失去連線用戶端的方案，儘管這些用戶端最需要協助。Client Conduit 能對無法存取基礎架構無線網路的用戶端進行即時、反應式診斷。

在 ad hoc 網路中，已有研究提出讓無線用戶端旁聽周圍環境，確保安全、正確的路由。[25] 提出 watchdog 機制，偵測自私節點造成的網路不可靠問題。基本概念是讓 watchdog 節點觀察鄰居，判定是否按預期轉送流量；其他研究進一步改良這種路由異常偵測 [7, 13]。

受 watchdog 啟發，我們也利用附近用戶端監控周遭 RF 條件及流量。在本架構中，watchdog 用於故障偵測，例如 Rogue AP，以及故障診斷，例如 Client Conduit、定位失去連線用戶端與隔離效能問題。

近期研究 [31] 使用旁聽無線用戶端，偵測熱點環境中的貪婪與惡意行為；這些技術與本工作處理不同面向，也可納入框架。

研究人員也已開發網際網路效能診斷技術。例如 Barford 等人 [9] 利用端點流量軌跡，將延遲分類為慢速伺服器、慢速用戶端或網路所致。EDEN 對無線網路有類似目標，但不要求兩端都支援流量追蹤。

Tulip [24] 是另一種診斷網際網路路徑延遲的方法。用戶端傳送 ICMP，利用不同元件的回應判定原因，例如封包遺失、封包順序改變或排隊延遲。EDEN 也使用 ICMP；但無線媒介的廣播特性，使 EDEN 能以新方式旁聽封包，診斷各元件延遲。

9. 未來工作

無線故障診斷仍有多項問題需要進一步研究，我們計畫近期探索：

• 我們提出部署環境中的 Rogue AP 偵測。相關問題是偵測未經授權 ad hoc 網路：已連至企業網路的使用者，例如透過有線網路連線，與未通過驗證用戶端建立 IEEE 802.11 ad hoc 網路。這與 Rogue AP 情境一樣，可能危害企業安全。
• 本文未討論用戶端驗證問題的根本原因分析。例如，系統可分析 IEEE 802.1x 協定訊息，判定驗證在哪個步驟失敗。
• 第 5.1 節說明附近有幾個已連線用戶端時，如何定位失去連線用戶端。若附近完全沒有已連線用戶端，應如何處理仍是問題。一種方法是讓用戶端記錄最後已知、仍有連線的位置，利用移動軌跡等啟發式方法，可能估計死角的大致位置。
• 診斷後的下一個合理步驟是恢復。故障被偵測後，需要判定系統應自動採取哪些步驟解決，而不一定需要網路管理員介入。

10. 結論

IEEE 802.11 網路日益普及，使故障偵測與診斷成為負責維護網路的 IT 管理人員的重要問題。值得注意的是，無線研究社群忽略了這些問題，可能因為維護問題要在大型部署完成後才浮現，而大型部署是相對近期的現象。

本文提出偵測多種故障的新方案，以及分析終端使用者效能問題的方法。初步結果顯示，定位 RF hole、偵測 Rogue AP 及診斷效能問題的機制有效，而且額外負擔低。

我們也顯示稱為 Client Conduit 的新機制可即時協助失去連線用戶端。這些技術結合以用戶端、AP 與後端伺服器共同診斷無線網路的一般架構，使系統獨特而實用。

IEEE 802.11 有效網路管理的整體問題範圍很廣。本文首次嘗試處理管理大型 802.11 部署的網路管理員向我們指出的一些關鍵問題。我們希望本文能促使其他研究人員進一步研究，提出最終讓 IEEE 802.11 網路順利運作的方案。

致謝

感謝 Graham Breeze 與 Don Berry 告知我們各種使用者及管理員的痛點。感謝 Alec Wolman 的意見，協助改善論文最終版本；他也提供桌機封包軌跡。Smitha Sarangarajan 提供建築中各 AP 的 SNMP 資料。

感謝 Abhi Abhishek、Hui Shen 與 Jiandong Ruan 協助 IM driver；Adeel Siddiqui 協助修正 miniport driver 的錯誤；Taroon Mandhana 協助 RPC 服務。也感謝 Pradeep Bahl、Jitendra Padhye、Venkat Padmanabhan、Siamak Poursabahian、Dan Simon、Dave Thaler 及匿名審稿者提供意見。

11. 參考文獻

以下保留原文作者、產品、會議與出版資訊；題名譯為繁體中文，英文題名一併列出方便檢索。網址依原文保留。

1. B. Aboba、D. Simon。〈PPP EAP TLS 驗證協定〉（PPP EAP TLS Authentication Protocol）。RFC 2716，1999 年 10 月。
2. AirDefense。〈無線區域網路安全〉（Wireless LAN Security）。http://airdefense.net。
3. AirMagnet。〈AirMagnet 分散式系統〉（AirMagnet Distributed System）。http://airmagnet.com。
4. AirWave。〈AirWave 管理平台〉（AirWave Management Platform）。http://airwave.com。
5. M. Allman、W. Eddy、S. Ostermann。〈以 TCP 估計遺失率〉（Estimating Loss Rates With TCP）。ACM Performance Evaluation Review，31(3)，2003 年 12 月。
6. Atheros Communications。http://www.atheros.com。
7. B. Awerbuch、D. Holmer、H. Rubens。〈透過強化學習，對抗主動式拜占庭攻擊者的可證明安全競爭性路由〉（Provably Secure Competitive Routing against Proactive Byzantine Adversaries via Reinforcement Learning）。JHU 技術報告，第 1 版，2003 年 5 月。
8. P. Bahl、V. N. Padmanabhan。〈RADAR：以射頻為基礎的建築內使用者定位與追蹤系統〉（RADAR: An Inbuilding RF-based User Location and Tracking System）。IEEE INFOCOM 論文集，以色列特拉維夫，2000 年 3 月。
9. P. Barford、M. Crovella。〈TCP 交易的關鍵路徑分析〉（Critical Path Analysis of TCP Transactions）。ACM SIGCOMM 論文集，瑞典斯德哥爾摩，2000 年 8 月。
10. J. Bellardo、S. Savage。〈量測封包重新排序〉（Measuring Packet Reordering）。ACM Internet Measurement Workshop 論文集，法國馬賽，2002 年 11 月。
11. D. Berry、G. Breeze。Microsoft IT 部門，私人通訊，2004 年。
12. Bluetooth SIG。〈定位工作小組〉（Location Working Group）。http://bluetooth.org。
13. S. Buchegger、J. Le Boudec。〈謠言傳播對行動 ad hoc 網路聲譽系統的影響〉（The Effect of Rumor Spreading in Reputation Systems for Mobile Ad-Hoc Networks）。WiOpt 論文集，法國，2003 年 3 月。
14. R. Chandra、P. Bahl、P. Bahl。〈MultiNet：使用單一無線網卡連接多個 IEEE 802.11 網路〉（MultiNet: Connecting to Multiple IEEE 802.11 Networks Using a Single Wireless Card）。IEEE INFOCOM 論文集，香港，2004 年 3 月。
15. Cisco。〈CiscoWorks 無線區域網路解決方案引擎〉（CiscoWorks Wireless LAN Solution Engine）。http://cisco.com。
16. Computer Associates。〈Unicenter 解決方案：建立成功的無線企業〉（Unicenter Solutions: Enabling a Successful Wireless Enterprise）。http://www.ca.com。
17. Ethereal：網路協定分析器（Ethereal: A Network Protocol Analyzer）。http://ethereal.com。
18. S. Floyd、M. Handley、J. Padhye、J. Widmer。〈單播應用的方程式型壅塞控制〉（Equation-Based Congestion Control for Unicast Applications）。ACM SIGCOMM 論文集，瑞典斯德哥爾摩，2000 年 8 月。
19. J. D. Foley、A. van Dam、S. K. Feiner、J. F. Hughes。《電腦圖學：原理與實務》，第 2 版（Computer Graphics Principles and Practice, 2nd Edition）。Addison Wesley，1990 年。
20. IBM Research。〈無線安全稽核工具〉（Wireless Security Auditor，WSA）。http://www.research.ibm.com/gsal/wsa。
21. IEEE Computer Society。〈IEEE 802.1x-2001：區域與都會網路 IEEE 標準：以埠為基礎的網路存取控制〉（IEEE 802.1x-2001 IEEE Standards for Local and Metropolitan Area Networks: Port-Based Network Access Control）。1999 年。〔年份依原文保留。〕
22. IEEE Computer Society。〈無線區域網路媒介存取控制（MAC）與實體層（PHY）規格〉（Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications）。IEEE Standard 802.11，1999 年。
23. A. Ladd、K. Bekris、A. Rudys、G. Marceau、L. Kavraki、D. Wallach。〈使用無線乙太網路的機器人式位置感測〉（Robotics-Based Location Sensing using Wireless Ethernet）。ACM MobiCom 論文集，美國喬治亞州亞特蘭大，2002 年 9 月。
24. R. Mahajan、N. Spring、D. Wetherall、T. Anderson。〈使用者層級的網際網路路徑診斷〉（User-level Internet Path Diagnosis）。ACM SOSP 論文集，美國紐約州 Bolton Landing，2003 年 10 月。
25. S. Marti、T. Giuli、K. Lai、M. Baker。〈減輕行動 ad hoc 網路中的不當路由行為〉（Mitigating Routing Misbehavior in Mobile Ad Hoc Networks）。ACM MobiCom 論文集，美國麻薩諸塞州波士頓，2000 年 8 月。
26. Microsoft Corp.。〈用於 IEEE 802.11 網路的 Native 802.11 框架〉（Native 802.11 Framework for IEEE 802.11 Networks）。http://microsoft.com。
27. B. Neuman、T. Tso。〈電腦網路的驗證服務〉（An Authentication Service for Computer Networks）。IEEE Communications，德國卡爾斯魯厄，1996 年 9 月。
28. J. Padhye、V. Firoiu、D. Towsley、J. Kurose。〈TCP 吞吐量建模：簡單模型及其實證驗證〉（Modeling TCP Throughput: a Simple Model and its Empirical Validation）。ACM SIGCOMM 論文集，加拿大卑詩省溫哥華，1998 年 9 月。
29. N. B. Priyantha、A. Chakraborty、H. Balakrishnan。〈Cricket 定位支援系統〉（The Cricket Location-Support System）。ACM MobiCom 論文集，美國麻薩諸塞州波士頓，2000 年 8 月。
30. L. Qiu、P. Bahl、A. Rao、L. Zhou。〈多跳無線網路中的故障偵測、隔離與診斷〉（Fault Detection, Isolation, and Diagnosis in Multihop Wireless Networks）。技術報告 MSR-TR-2004-11，Microsoft Research，美國華盛頓州雷德蒙德，2003 年 12 月。
31. M. Raya、J. P. Hubaux、I. Aad。〈DOMINO：偵測 IEEE 802.11 熱點中貪婪行為的系統〉（DOMINO: A System to Detect Greedy Behavior in IEEE 802.11 Hotspots）。MobiSys 論文集，美國麻薩諸塞州波士頓，2004 年 6 月。
32. C. Rigney、A. Rubens、W. Simpson、S. Willens。〈遠端驗證撥入使用者服務（RADIUS）〉（Remote Authentication Dial In User Service (RADIUS)）。RFC 2138，IETF，1997 年 4 月。
33. H. Schulzrinne、S. Casner、R. Frederick、V. Jacobson。〈RTP：即時應用的傳輸協定〉（RTP: A Transport Protocol for Real-Time Applications）。RFC 1889，IETF，1996 年 1 月。
34. R. Stevens。《TCP/IP 詳解，第 1 卷：協定》（TCP/IP Illustrated (Vol. 1): The Protocols）。Addison Wesley，1994 年。
35. Symbol Technolgies Inc.。〈SpectrumSoft：無線網路管理系統〉（SpectrumSoft: Wireless Network Management System）。http://www.symbol.com。
36. R. Want、A. Hopper、V. Falcao、J. Gibbons。〈Active Badge 定位系統〉（The Active Badge Location System）。ACM Transactions on Information Systems，10(1)，1992 年 1 月。
37. Wibhu Technologies Inc.。SpectraMon。http://www.wibhu.com。
38. WildPackets Inc.。〈Airopeek 無線區域網路分析器〉（Airopeek Wireless LAN Analyzer）。http://www.wildpackets.com。
39. WinDump：Windows 版 tcpdump（WinDump: tcpdump for Windows）。http://windump.polito.it。
40. Y. Zhang、L. Breslau、V. Paxson、S. Shenker。〈網際網路流量速率的特性與起源〉（On the Characteristics and Origins of Internet Flow Rates）。ACM SIGCOMM 論文集，美國賓夕法尼亞州匹茲堡，2002 年 8 月。
41. Y. Zhang、N. Duffield、V. Paxson、S. Shenker。〈網際網路路徑特性的穩定性〉（On the Constancy of Internet Path Properties）。ACM Internet Measurement Workshop 論文集，美國加州舊金山，2001 年 11 月。