目錄

簡介

背景資訊

成功擷取的檢查表

監聽器工具

Mac OS X 無線監聽工具

airportd

airport 公用程式

tcpdump

Wi-Fi Diagnostic

Airtool

使用Windows 7和3.4進行無線探查（已停用的方法）

簡介

在監聽器模式下使用思科輕型存取點(LAP)進行無線監聽

簡介

設定步驟

步驟 1. WLC/ AP 端

步驟 2.監聽器端：Wireshark

步驟 3.監聽器端：OmniPeek

使用 Cisco® Autonomous (IOS) AP 進行無線監聽

將擷取檔案上傳至 TAC 服務請求

監聽器分析

802.11 監聽器擷取分析 - 實體層

簡介：無線封包擷取資料中的實體層資訊

無線封包標頭 — 範例

802.11嗅探器捕獲分析- Wireshark過濾

簡介

Wireshark 篩選條件 — WLAN

目標

必要條件

為什麼需要捕獲無線嗅探器蹤跡

為什麼需要使用無線嗅探器捕獲過濾器

何時使用顯示過濾器和捕獲過濾器

如何篩選

選單列

主要工具列

篩選器工具列

封包清單窗格

封包詳細資訊窗格

封包位元組窗格

狀態列

初始狀態列

使用擷取篩選條件

顯示篩選條件

使用上色篩選規則

802.11 監聽器擷取分析 — 管理訊框與開放式驗證

簡介

802.11 訊框與開放式驗證

802.11 用戶端驗證程序

管理訊框

控制訊框

資料訊框

參考資料

802.11 監聽器擷取分析 — 具備 PSK 或 EAP 的 WPA/WPA2

WPA-PSK (TKIP)

WPA2-PSK (AES/TKIP)

如何使用Wireshark解密無線資料包捕獲上的WPA2 AES資料

要求:

程序

WPA/WPA2 Enterprise

具備 dot1x (EAP-TLS) 的 WPA (TKIP)/WPA2 (AES)

802.11 監聽器擷取分析 — 多點傳送

簡介

解決方案

WLC 上的 IGMP 偵聽

使用多點傳送模式的指導原則

設定多點傳送（使用「多點傳送 — 多點傳送」模式）

在無線 LAN 控制器上

有線網路上的多點傳送組態

封包擷取

拓撲

MCAST 流量產生工具

在 MCAST 產生器上擷取的有線 Wireshark 封包

在 MCAST 封包產生器上擷取的 Windows Netmon

Wireshark 在無線用戶端的無線介面上進行擷取

Netmon 在無線用戶端的無線介面上進行擷取

802.11 監聽器擷取分析 — Web 驗證

簡介

組態 Webauth

WLCC 設定

以下是客戶端嘗試連線時的客戶端調試

參考資料：

簡介

本文說明收集良好無線監聽器追蹤資料，以分析和疑難排解 802.11 行為的程序。

背景資訊

此程序可能難以執行，且需耗費大量時間。謹記幾個重點能有助於簡化及加快程序。無線監聽功能可幫助您釐清要執行的操作。您可以透過無線方式擷取原始無線訊框，如同無線監聽裝置本身一樣。

成功擷取的檢查表

第1步：由於嗅探裝置、客戶端裝置和AP使用射頻生成無線電進行傳輸或接收，因此讓無線嗅探器靠近目標裝置（客戶端機器）會有所幫助。監聽裝置能大致清楚擷取到用戶端裝置透過無線方式接收到的資料。

步驟 2：使用獨立裝置進行無線監聽。如果在測試的裝置上（您嘗試用來取得無線追蹤資料的用戶端機器）進行無線監聽，無法取得良好的無線監聽追蹤成效。

步驟 3：設定擷取作業前，先瞭解用戶端裝置所使用的確切 802.11 頻道與頻帶將您的監聽器鎖定至感興趣的頻道-請勿使用監聽器的掃描頻道模式！  (使用掃描通道時，監聽器大約每秒會在通道之間循環一次。這對於現場勘測或查詢惡意程式很有用，但當您嘗試捕獲802.11問題時，則不然。)

此外，用戶端裝置可能會漫遊至另一個位於不同 RF 頻道或頻帶的 AP，所以您必須考量這點妥善規劃。以 802.11b/g (2.4 GHz) 環境而言，通常可能需要使用三個頻道監聽器，這涉及在監聽裝置上使用3個無線網路卡，每個介面卡都設定為通道1、6和11。USB無線介面卡最適合這種型別的設定。

步驟 4：若您是要疑難排解 5 GHz，頻道數會大幅增加。由於您沒有足夠的卡來捕獲所有通道，因此最好在周圍存取點上運行不超過4個通道。

第5步：如果客戶端從一個通道漫遊到另一個通道時，您可以重現該問題，那麼雙通道嗅探就足夠了。  但如果您只能使用單一頻道監聽器，請監聽用戶端漫遊的目標頻道。

步驟 6：一律使用 NTP 同步監聽器。  封包擷取需搭配偵錯擷取以及其他有線和/或無線擷取，加以整理。  即使時間戳記誤差只有一秒鐘，也會讓整理作業更難完成。

第7步：如果捕獲時間較長（小時），則配置嗅探器以每30MB左右剪下一個新捕獲檔案。  為避免塞滿硬碟空間，您必須提高寫入檔案數量的上限。

附註：若使用短期保護間隔，Linksys USB600N 無法穩定地收集 11n 封包。短期保護間隔封包會遺漏 20% 到 30%。如有必要，可將 WLC 設定變更為僅使用時間較短的長期防護間隔，這只能是臨時配置更改。命令為config 802.11 {a | b}11nsupport guard-interval {any | long}。

監聽器工具

使用搭載 OS X 10.6 以上版本的 Mac 進行無線監聽

Mac OS X 上內建工具可擷取無線追蹤，因此能在 Mac 上進行無線監聽。    不過，根據執行的 OS X 版本而定，命令也可能有所不同。這份文件涵蓋 OS X 10.6 到最新版本的命令。在最新的 Macbook 中偏好無線診斷方法。建議 Macbook 監聽器效能須至少與要監聽的用戶端一樣（以 802.11n Macbook 監聽 802.11ac 智慧型手機並非最佳選擇）。

Mac OS X 無線監聽工具

- airportd (10.6-10.8)

- airport 公用程式 (10.6 - 10.8)

- tcpdump (10.8)

- Wi-Fi Diagnostics (10.7->10.12)

- Wireshark (10.6 - 10.8)

- 第三方工具：Airtool

airportd

如果運行OS X 10.6(Snow Leopard)或更高版本，您可輕鬆地使用命令列實用程式airportd。

步驟如下：

- 使用命令+空格鍵組合鍵在螢幕的右上角顯示搜尋對話方塊，並鍵入單詞terminal。此操作可搜尋終端應用。選擇此應用程式並執行。終端機視窗可能會出現。

- 開啟終端機視窗後，可以在 RF 頻道 11 (802.11b/g) 執行下列命令，以擷取無線監聽器追蹤資料：

sudo /usr/libexec/airportd en1 sniff 11

請謹記以下事項：

- 系統會提示您輸入帳戶密碼以進行驗證。

- 您不能指定擷取檔案的名稱或放置輸出檔案的位置。

- 擷取期間，無線連線會無法使用。

- 若您使用的是 Air，無線介面卡是 en0 而非 en1。

作業結束後，請按 Cntl + C 停止追蹤，公用程式會顯示名稱以及擷取檔案的位置。檔案格式是標準 wireshark PCAP 檔案，可以透過 Wireshark 在 MAC 或 Windows 上讀取。

airport 公用程式

airport 公用程式不是監聽器程式，但可以提供無線 LAN 的相關資訊。此外，這個程式也能設定預設無線頻道，這對無法自行設定頻道的監聽器程式（tcpdump、Wireshark）來說非常重要。

附註：通往 airport 公用程式的路徑很雜亂，因此不妨從路徑中的目錄設定符號連結，例如：# sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport.

設定無線頻道

# sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport --channel=48

傾印顯示的SSID/BSSID資訊

# sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -s

SSID      BSSID                  RSSI 頻道 HT CC  SECURITY（驗證/單點傳播/群組）

Test     00:24:97:89:cb:41    -53    11              Y   --    WPA(PSK/TKIP/TKIP) WPA2(PSK/AES/TKIP)

Test2   00:24:97:89:cb:40    -53    11              N   --    WPA(PSK/TKIP/TKIP)

Guest  00:22:75:e6:73:df     -64    6,-1            Y   --    WPA(PSK/AES,TKIP/TKIP) WPA2(PSK/AES,TKIP/TKIP)

目前關聯的詳細資訊

# sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport –I

agrCtlRSSI:             -54

agrExtRSSI:            0

agrCtlNoise:            -89

agrExtNoise:           0

state:                     running

op mode:                station

lastTxRate:             300

maxRate:                300

lastAssocStatus:     0

802.11 auth:            open

link auth:                wpa2-psk

BSSID:                   0:24:97:95:47:60

SSID:                     GuestNet

MCS:                     15

channel:                 36,1

tcpdump

Tcpdump 是 OS X 隨附的命令列公用程式，可執行封包擷取（與 tshark 綁定的 tshark 公用程式非常類似）。  使用 tcpdump 執行無線封包擷取：

- 首先，使用 airport 公用程式來設定頻道，方法如上所示。

- 接著執行無線封包擷取，並將資料儲存為檔案。  完成後，請輸入 Control/C 結束。

範例：

bash-3.2# tcpdump -I -P -i en1 -w /tmp/channel-11.pcap

tcpdump: WARNING: en1: no IPv4 address assigned

tcpdump: listening on en1, link-type IEEE802_11_RADIO (802.11 plus radiotap header), capture size 65535 bytes

^C

897 packets captured

968 packets received by filter

0 packets dropped by kernel

bash-3.2#

Wi-Fi Diagnostic

最簡單的擷取方式是使用稱為「Wi-Fi Diagnostic」的圖像式程式。

若要存取此程式，請按住 Alt 鍵並按一下右上角的 Wi-Fi 圖示（通常會在這裡選取要連線的 SSID）。

按一下清單中的Open Wireless diagnostics選項。

執行疑難排解預設報告的視窗會隨即顯示。通常這「不是」您會感興趣的報告。

讓該視窗保持開啟，然後前往畫面頂端的選單列。按一下視窗。這時畫面中會列出工具清單（很適合進行站台調查或訊號分析）。在無線監聽器擷取範圍內，按一下要使用的監聽器選項。

接著您只需要選擇主要頻道以及頻道寬度。

監聽器擷取資料會儲存在桌面上，或是儲存於 Mac OS Sierra 的 /var/tmp/。

Airtool

另外，一些第三方工具也支援許多 Mac OS X 版本，提供更容易選擇頻道的方法，強化內嵌的監聽功能。其中一個例子是 Airtool。

使用Windows 7和3.4進行無線探查（已停用的方法）

簡介

有了Microsoft Network Monitor ( 3.4)，您現在可以使用標準無線介面卡，在Windows 7中執行一些不錯的802.11a/b/g （或許11n）無線探查。  從儲存的檔案可由最新的（1.5及更高版本） Wireshark讀取，但無法在OmniPeek中讀取。請務必注意，Microsoft已不再支援，而且通常無法在11n和11ac介面卡上正常運作（大部分架構遺失）。

XP SP3 支援 Netmon 3.4，但執行 XP 時不支援無線監聽。至於 Vista，則提供混合式體驗。

本文檔的Netmon詳細部分已被刪除，因為此部分已被棄用，無法可靠地捕獲802.11ac幀。

詳情請參閱：使用 Netmon 在 Windows 進行無線監聽

使用監聽器模式下的 Cisco Lightweight Access Point (LAP) 進行無線監聽

簡介

您可以在監聽器模式下使用 Cisco WLC 與 LAP，並搭配監聽器（搭配 Wireshark 可獲得最佳結果。自第 10 版起，Omnipeet 會以不同方式解密通訊協定）。

單一有線監聽器可以收集多個 AP 的封包，因此執行多頻道追蹤時，這個方法非常有用。在靜態情況下，如果能移動監聽器 AP，就可以使用這個方式有效替代其他監聽選項。

對於漫遊情況，嗅探器AP通常安裝在客戶端漫遊的AP附近，這樣可以報告靜態AP的「視點」，而不是客戶端。

為了在漫遊時從客戶端的角度檢視RF，可以使用帶有多個無線網絡卡的筆記型電腦捕獲多通道無線跟蹤，該筆記型電腦可以使用測試客戶端。

設定步驟

步驟 1.   WLC/ AP 端

使用監聽器模式 LAP 收集追蹤資料的步驟如下。

設定監聽器模式下的 AP：

AP可能重新啟動，因此無法為客戶端提供服務。 一旦AP重新加入WLC，請配置AP的無線電（802.11b/g/n或802.11a/n）：

- 指定監聽器 IP 位址

- 選擇頻道

- 啟用監聽

監聽器會從 WLC 管理 IP 位址（來源連接埠為 UDP/5555，目的地為 UDP/5000）收到使用 airopeek 通訊協定封裝的 802.11 流量。

步驟 2.監聽器端：Wireshark

如果使用Wireshark接收流量，請執行以下步驟：

- 設定擷取選項，僅接收來自監聽 AP 的流量。若您僅針對連接埠 UDP 5000 設定篩選條件，當 AP 必須分割封包時，擷取資料就會遺漏 IP 分段（如果監聽需新增 PEEKREMOTE 封裝的 1500 位元組長訊框，就會發生此情況）：

您可自行決定是否使用此篩選條件，但強烈建議使用，因為這能在擷取作業中排除所有非無線相關流量。考慮到 WLC 會將流量傳送至 UDP 連接埠，且監聽器端沒有應用程式接聽，這會導致 WLC 送出的每個封包都出現 ICMP 連接埠無法連線回應。

雖然這是預期中的狀況，但此篩選條件也有助排除沒有用處的流量，以免追蹤資料量更龐大，更難以讀取。

接著，開始進行擷取：

擷取流量必須解碼為 PEEKREMOTE，以便看見 802.11 流量：

- 現在可以看到802.11流量：

圖中顯示的 RF 資訊（即頻道、訊號強度、雜訊等）都是由 AP 新增。

步驟 3.監聽器端：OmniPeek

使用 OmniPeek 當成監聽器模式下 WLC/AP 的流量串流接收器時，優先要務是在擷取選項視窗的介面卡選單下建立 Cisco 遠端介面卡：

至少須有一個介面卡，名稱是必填欄位，但如果您不想讓 OmniPeek 篩選來自特定 WLC 的傳入流量，可將「IP 位址」欄位留空。

此案例不必篩選掉任何流量（例如 ICMP 連接埠無法連線），因為 OmniPeek 會在 UDP 連接埠接聽，專門擷取來自無線 LAN 控制器的資料流。

開始擷取前，請在 OmniPeek 主視窗中確認設定：

此時就能開始擷取，產生的結果為一筆追蹤資料，內容包含 AP 所回報的 RF 資訊：

注意：預設情況下，OmniPeek遠端介面卡會獲取AP自身傳送的時間戳。此資訊與AP時鐘無關，因此產生的時間戳可能不正確。如果使用單個嗅探器AP，則時間戳可能錯誤，但至少是一致的。如果使用多個 AP 作為監聽器，情況就非如此，因為每個 AP 都會傳送自己的時間戳記資訊，導致合併擷取資料時出現奇怪的時間跳躍狀況。

解決方案

您可以明確告訴 OmniPeek 使用本機監聽器 PC 時脈設定封包時間戳記。

這能同時解決使用單一和多個 AP 等情況的問題，只要執行 OmniPeek 的 PC 具備 NTP 同步時脈，時間戳記就會正確且一致。

操作步驟：

在 OmniPeek 中執行以下步驟：

1. 定位至工具>選項>分析模組。

2. 搜尋 Cisco 遠端介面卡，然後按兩下以顯示選項。

3. 按一下「時間戳記」選項，接著按一下確定，然後再次測試擷取。

使用 Cisco® Autonomous (IOS) AP 進行無線監聽

您可以使用自主 AP 來收集無線封包擷取。以下說明列出了如何執行空中捕獲。

1. 進入您要執行擷取的 dot11radio 介面。將站點角色設定為嗅探器，增加可以運行Wireshark和收集捕獲的伺服器/PC IP，並選擇通道。您使用monitor frames 命令指定的埠可以是AP傳送捕獲的目標UDP埠。

指令

目的

步驟 1

int {d0 | | d1}

進入介面設定命令模式，以設定無線電介面。

步驟 2

站台角色監聽器

將站台角色變更為監聽器。

步驟 3

通道號碼

選取要以監聽器模式運作的頻道。

步驟 4

no shut

將介面回復到非關閉狀態。

步驟 5

exit

結束介面設定命令模式。

步驟 6

監聽器 IP 位址 目的地 IP 連接埠 連接埠號碼

設定 AP 要將所有封包重新導向至哪個 IP 位址與連接埠號碼。您可以在 1024 到 65535 之間的任一連接埠號碼上指定 IP 位址。

步驟 7

啟用 Wireshark

若您在端點使用 Wireshark，此命令會將 Wireshark 標頭新增至封包。

設定範例：

ap(config)# int d0

ap(config)-if# station-role sniffer

ap(config)# channel 11

ap(config)# no shut

ap(config)# exit

ap(config)# sniffer ip-address 10.10.10.1 30 port 5555

ap(config)# wireshark enable

2. 在伺服器/PC 上啟動 Wireshark。導覽至「Capture」(擷取) >「Options」(選項)。選擇乙太網路 NIC (LAN) 並新增篩選條件，僅擷取您在步驟 1 所指定 UDP 連接埠的流量。

3. 開始進行 Wireshark 擷取。

將擷取檔案上傳至 TAC 服務請求

若擷取檔案太大，無法以電子郵件傳送，您可將其上傳至自己的 TAC 服務請求：

https://tools.cisco.com/ServiceRequestTool/query/

輸入您的 SR 編號，然後按一下檔案上傳。

監聽器分析

若要分析無線擷取，請參閱以下連結。連結的排列順序即為閱讀順序，因為每份文件的內容都是在前一份文件的基礎上撰寫而成。  請記住，閱讀任何無線追蹤時，最好瞭解802.11無線規格。  這些文件能有效幫助您瞭解封包流量，以及可從無線追蹤資料中獲取哪些資訊，但用途不包括用於講授 802.11 無線規格。

802.11 監聽器擷取分析 - 實體層

簡介：無線封包擷取資料中的實體層資訊

擷取的封包中包含訊框資料的複本，但每個訊框前都會加上中繼資料標頭，告知擷取訊框的方式。  對於有線資料包，後設資料並不多。只有訊框編號、封包擷取日期與封包長度。  執行有線資料包分析時，您很少會過於關注物理層，因為物理層的誤位元速率為10^10，所以您通常假定捕獲的位與它們聲稱的一樣。

但無線封包完全是另一回事。與有線相比，無線的實體層更加複雜混亂。  著手嘗試根據上層深入分析擷取到的資料時，最好對所擷取的實體層有所瞭解，  如果物理層工作不正常，那麼上層將永遠不會有機會。

請特別注意實體層在以下方面的品質：

訊號強度（RSSI、訊號強度、訊雜比。）  如果可以的話，最好特別留意 RSSI。監聽介面卡接收封包時的功率等級（單位為 dBm）代表以下強度：

- RSSI < -90 dBm：訊號非常微弱，接收器幾乎快要接收不到。

- RSSI -67dBm：訊號相當強，思科認定這是支援 WLAN 語音的適當強度。

- RSSI > -55dBm：訊號非常強。

- RSSI > -30dBm：監聽器就在傳輸器旁邊。

頻道（頻率）。由於無線 LAN 可支援 3 到 25 個頻道，因此您必須準確瞭解所取得的擷取資料來自哪一個頻道。  如果意圖從特定AP獲取嗅探，請將嗅探鎖定到該AP的通道，並驗證捕獲是否在該通道上，否則捕獲可能毫無價值。

.

資料傳輸速率從 1 Mbps 到 300 Mbps 不等，甚至更快。  若要瞭解為何資料無法總是順利從傳輸器傳送到接收器，您必須知道使用的資料傳輸速率為何。  對於54Mbps調製的資料包，80dBm的「邊際」RSSI可以非常可怕地工作，但在6Mbps時可以非常令人滿意。

無線封包標頭 — 範例

不同的無線監聽器可能會使用不同的中繼資料標頭格式來編寫無線實體層程式。  請務必注意，資訊的精準度是根據特定介面卡硬體與使用的磁碟機而定。   通常會考慮某些值，例如雜訊。

以下範例特別標示資料傳輸速率、頻率與 RSSI 等欄位。

Mac OS X 10.7 無線診斷（Broadcom 介面卡）

OS X 10.7 使用 Radiotap v0 標頭，看起來就像以下 Wireshark 中的樣子：

OmniPeek 6.8（Ralink USB 介面卡）

在 Wireshark，OmniPeek 擷取會使用 Airopeek 標頭，看起來像這樣：

Wireshark（截至 1.6.x 版）不知道如何解碼 OmniPeek 擷取資料中的所有無線中繼資料。在 OmniPeek 中檢視相同訊框，則可看見訊號 dBm、雜訊等級與雜訊 dBm：

Netmon 3.4

將無線檔案應用為Wireshark列。

如果您已將無線欄位以欄的形式套用，通常能更容易透過無線監聽瞭解實際動態。以下是操作方法：

1.在資料包詳細資訊部分(首先展開適用的報頭部分（如有必要）)找到感興趣的欄位，然後按一下右鍵該欄位。  選擇Apply as Column：

2.  新的欄會隨即出現。  此時您可以視需求調整大小、重新命名（在欄標題按一下滑鼠右鍵，然後選取編輯欄詳細資訊）以及移動欄。

3.  針對其他想使用的欄重複以上步驟。  現在您能更妥善處理擷取資料中的實體層相關內容。

4.  套用新欄後，下次執行 Wireshark 時，就能使用該欄（如果沒看到，請在欄標題上按一下滑鼠右鍵，並選取顯示 欄）。

802.11嗅探器捕獲分析- Wireshark過濾

簡介

802.11 監聽器擷取分析 — Wireshark 篩選條件

Wireshark 篩選條件 — WLAN

目標

本文檔可以幫助您瞭解如何設定wireshark和分析在wireshark程式中使用稱為wireshark過濾器的多功能工具的相關資料包。

必要條件

除非對通訊協定、網路拓撲與執行監聽器追蹤的資料點有充足認識與瞭解，否則 Wireshark 工具本身對於完成疑難排解程序並沒有幫助。無論是要疑難排解有線網路，還是在封包進入網路前以無線方式擷取封包的無線網路，都是如此。 AP 會刪除無線 MAC 位址。

為什麼需要捕獲無線嗅探器蹤跡

在使用有線監聽器追蹤的有線網路上檢查流量或資料，卻找不到關注的封包時，就需釐清封包在哪裡遺失了。出於疑惑，您可能會驗證封包是否成功通過來源的第一個點，確認無線連線是否正常運作（是否在無線傳輸過程中遺失）。如果封包並未成功透過無線方式完成傳輸，很顯然就是封包不見了，或是 AP 無法轉譯或傳送至有線端 DS 或分佈系統。此時就必須使用無線監聽器追蹤來識別無線網路問題，並找出發生問題的位置。

為什麼需要使用無線嗅探器捕獲過濾器

在排除網路相關故障時，存在許多依賴關係，而且所有這些依賴關係都存在於分層模型中，而且每個資料層都取決於其下層。有許多元件或網路元件，以及裝置的設定和正確操作，可協助我們達到順暢的網路執行效果。網路停止運作時，您必須使用合乎邏輯的方式找到問題所在。即使找到問題，仍很難找出故障點的精確位置。在這些情況下，監聽器就能派上用場。就算採用最佳做法，且對疑難排解與相關技術已有深入瞭解，這個疑難排解程序還是可能相當複雜。問題在於，如果捕獲透過網路裝置傳輸的資料包，可能會有大量的檔案，如果捕獲足夠長的時間，並且其中包含大量資料包詳細資訊，則最終可能達到1G。在如此大量的資料下，找出問題可能非常耗時，並且會成為一項非常困難的任務。 過濾可以幫助您快速發現問題，消除不需要的流量，並同時減少要關注的變數。如此一來，您能快速瞭解收集到的流量之中是否有您想要關注的流量。

- 「顯示」篩選條件：擷取大量資訊後，此篩選條件可讓您只顯示關注的封包.

- 「擷取」篩選條件：一開始您就知道要關注哪些封包，此篩選條件可讓您只擷取這些封包.

- 用於為資料包著色的過濾器-用於增強顯示過濾器或捕獲過濾器的視覺幫助，或者用於不使用任何過濾器將許多不同資料包歸類為用於高級方法的各種顏色。

何時使用顯示過濾器和捕獲過濾器

若您知道要尋找什麼內容，且嘗試要在該事件的執行流量中驗證，建議使用「擷取」篩選條件。在高流量環境中執行數小時便能加以擷取，這有助於將收集到的資料檔案大小維持在合理範圍內。

如果您不確定導致問題的原因，並且它更具有行為隨機性，則在問題發生模式的可能窗口內運行資料包捕獲較短時間（例如一兩個小時），並捕獲所有流量。接著使用「顯示」篩選條件，僅顯示您要尋找的資訊。 除了此方法外，您也可以查看所有擷取資料，並使用上色規則為特定封包類型指派不同顏色，方便進行排序或辨別封包流量。

如何篩選

您必須瞭解典型 Wireshark 監聽器追蹤資料的各個欄位，並將資料細分及定義每個欄位。

您專注於使用過濾功能需要瞭解的3個專案。

- 擷取篩選條件

- 顯示篩選條件

- 顏色規則篩選條件

在您深入瞭解詳細資訊之前，以下是wireshark的嗅探器捕獲窗口的示例。

選單列

這是 Wireshark 視窗中的選單列。

選單列包含以下項目：

- 檔案：此選單的選項可開啟和合併擷取檔案、完整或部分儲存/列印/匯出擷取

檔案，以及退出 Wireshark。

- 編輯：此選單的選項可尋找封包、參考時間或標示一或多個

封包、處理組態設定檔，以及進行偏好設定；（剪下、複製和貼上

不會在此實作）。

- 檢視：此選單可控制擷取資料的顯示方式，包括封包的

packets （封包，字型的縮放功能）在個別視窗中顯示封包，展開和

收合封包詳細資料中的樹狀結構。

- 前往：此選單的選項可前往特定封包。

- 擷取：此選單可讓您開始或停止擷取作業，以及編輯擷取資料的篩選條件。

- 分析：此選單的選項可操控顯示篩選條件、啟用或停用

剖析協定，配置使用者指定的解碼並使用TCP資料流。

- 統計-此選單包含用於顯示各種統計窗口（包括彙總）的專案

提供已擷取封包的摘要，以及顯示通訊協定階層統計資料

還有.

- 電話：此選單的選項可顯示各種與電話相關的統計資料視窗，

包括媒體分析、流量圖、顯示通訊協定階層統計資料

。

- 工具：此選單包含 Wireshark 提供的各種工具，如建立防火牆。

ACL 規則。

- 間隔：此選單的選項可顯示 Wireshark 的時間間隔資訊。

- 說明：此選單的選項能為使用者提供說明文件，例如基本操作說明和手冊。

不同命令列工具的手冊、線上存取某些網頁，

以及對話的一般項目。

主要工具列

主要工具列會提供使用者功能表中經常使用的項目。此工具列無法自訂，如果需要在螢幕上騰出更多空間來顯示更多封包資料，可使用「檢視」選單隱藏此工具列。如同在選單中一樣，只能使用在目前程式狀態中有用的專案。其他專案可能會呈現灰色。（例如，如果尚未載入捕獲檔案，則無法儲存捕獲檔案）。

篩選器工具列

篩選器工具列可快速編輯及套用顯示篩選條件。

篩選：開啟篩選建構通話方塊、擷取篩選與顯示篩選通話方塊。

- 篩選此區域的輸入內容，以輸入或編輯顯示篩選條件字串運算式。輸入的同時，系統會檢查篩選條件字串的語法。如果輸入的字串不完整或無效，背景會變成紅色；輸入的字串有效時則會變成綠色。您可以按下拉箭頭，在清單中選取之前輸入過的篩選條件字串。即使程式重新啟動，下拉清單中的項目仍可持續使用。

- 變更此欄位中的內容後，請記得按下「套用」按鈕（或Enter/Return鍵），將這個篩選字串套用至顯示。 這個欄位會顯示目前使用中的篩選條件。

- 運算式：標示為「新增運算式……」的中間按鈕會開啟一個通話方塊，您可以在其中編輯協定欄位清單中的顯示篩選條件，如<篩選運算式>通話方塊中所述。

- 「清除」會重設目前的顯示篩選條件，並清除編輯區域。

- 「套用」會套用編輯區域中當前的值，作為新的顯示篩選條件。

封包清單窗格

「Packet List」(封包清單) 窗格會顯示目前擷取檔案中的所有封包。

封包清單中的每一行都會對應至擷取檔案中的一個封包。如果您在此窗格中選擇一行，則更多詳細資訊將顯示在Packet Details和Packet Bytes窗格中。

封包詳細資訊窗格

資料包詳細資訊窗格以更詳細的形式顯示當前資料包（在資料包清單窗格中選擇）。

封包位元組窗格

Packet bytes（資料包位元組）窗格顯示當前資料包(在Packet List（資料包清單）窗格中選擇)的資料

的資料。

狀態列

狀態列會顯示資訊性訊息。一般來說，左側會顯示內容相關資訊，中間顯示當前的封包數量，右側顯示選取的組態設定檔。 拖曳文字區域間的滑桿可變更大小。

初始狀態列

尚未載入擷取檔案時會顯示此狀態列，例如剛啟動 Wireshark 時。

索引標籤名稱的內容選單（按一下滑鼠右鍵）會顯示所有可用頁面的清單。 如果窗格尺寸太小，無法顯示所有標籤，這就相當實用。

狀態列

狀態列會顯示資訊訊息。一般來說，左側會顯示內容相關資訊，中間顯示當前的封包數量，右側顯示選取的組態設定檔。 拖曳文字區域間的滑桿可變更大小。

已載入擷取檔案的狀態列。

- 左側顯示擷取檔案的資訊、檔案名稱、大小以及擷取經過時間。

- 左側的彩色項目符號會顯示目前載入的擷取檔案中所找到最高的專家資訊等級。將滑鼠懸停在此圖示上將顯示專家資訊級別的文本說明，按一下圖示時，該圖示會顯示「專家資訊」對話方塊。

- 中間顯示擷取檔案中目前的封包數量。

畫面上會顯示以下值：

- 封包：擷取的封包數量

- 已顯示：目前顯示的封包數量

- 已標記：已標記的封包數量

- 已捨棄：已捨棄的封包數量（只有在 Wireshark 無法擷取所有封包時才會顯示此項目）

- 已忽略：已忽略的封包數量（只有封包遭到忽略時才會顯示此項目）

- 右側顯示已選取的組態設定檔。按一下狀態列的這個部分就會顯示選單，列出所有可用的組態設定檔，從此清單中選取項目即可變更組態設定檔。

使用擷取篩選條件

按一下Capture Interfaces options（捕獲介面選項）並從下拉選單中選擇Network adapter（網路介面卡），該下拉選單用於捕獲PC上網路中正在運行的資料包。按一下「擷取篩選條件」並輸入篩選條件名稱與字串，或直接在方塊中輸入您知道的篩選條件字串。 然後點擊按鈕。 現在 Wireshark 監聽器程式會從所有通類型的訊協定中巨量流量的即時封包中，擷取您感興趣的封包。

顯示篩選條件

載入擷取檔案後，您就可設定篩選條件，以顯示您關注的封包，或避免顯示無關的封包。您可以使用簡單的篩選條件運算式，或結合使用邏輯運算子的運算式，建立複雜的篩選條件字串。

按一下分析。選擇顯示篩選條件。

本範例會建立一個篩選條件，從 802.11 無線封包擷取追蹤資料中篩選出信標封包，如以下黃色標示處所示。

與顯示篩選條件類似，按一下尋找封包後套用篩選條件，即可找到特定封包。

找到篩選按鈕，然後在篩選條件方塊中輸入篩選值。如果不知道字串，可以按一下篩選器進一步探索，接著按新增按鈕，為篩選條件字串命名並套用，或在方塊中輸入篩選條件字串。若您不知道具體篩選條件字串，可以選擇運算式按鈕，使用顯示的各種通訊協定選項組成篩選條件字串。

選擇要使用的項目，展開更多選項以從中選擇。

您也可以根據要輸入的值，選擇使用「邏輯運算子」方塊並套用，以完成篩選條件。

您可以建構顯示篩選條件，使用多個不同的比較運算子來比較值。

使用上色篩選規則

Wireshark 中有一個非常實用的機制，是將封包彩色化。您可以設定讓 Wireshark 根據篩選條件為封包上色，藉此強調您要關注的封包。 您可以設定Wireshark，使其根據您選擇建立的過濾器為資料包著色。 這可讓您強調您（通常）感興趣的封包。

此範例會根據提及的篩選條件，依信標、確認、探查回應、取消驗證等條件為封包上色。

按一下檢視。從主工具列中選擇「著色」規則或「編輯著色規則」。

選取後就會開啟上色規則，您也可以使用新增或編輯來新增上色篩選條件。選擇封包或編輯篩選條件字串，並指派或調整想使用的顏色。

在「編輯顏色」對話方塊中，只需輸入顏色濾鏡的名稱，然後在「濾鏡」文字欄位中輸入濾鏡字串。編輯顏色過濾器對話方塊中顯示值beacon和wlan.fc.type_subtype == 8，這意味著顏色過濾器的名稱為Beacon，並且過濾器可以選擇型別wlan.fc.type_subtype == 8（信標過濾器字串）的協定。 輸入這些值後，您就可以選擇符合篩選條件運算式之封包的前景與背景顏色。按一下前景顏色...或背景顏色...即可完成。

以「tac80211color」檔案匯出或建構上色篩選條件並儲存，這個功能非常實用，如範例中所示。這是可以匯入的檔案，因此可在疑難排解資料夾中建立多個上色規則檔案，以便在每次疑難排解時作為範本使用。

您可以依需求發揮創意，量身打造上色篩選條件範本檔案，例如路由、WLAN、交換等。根據您要疑難排解的問題為篩選條件檔案上色並匯入。

您可以到支援論壇 - 上色規則下載好用的上色規則並善加利用。

這是匯入並套用顏色篩選檔案「tac80211color」後，

tac80211color已導入並應用。

802.11 監聽器擷取分析 — 管理訊框與開放式驗證

簡介

802.11 監聽器擷取分析 — 管理訊框與開放式驗證

802.11 訊框與開放式驗證

嘗試分析或疑難排解使用 802.11 封包分析器的無線 LAN 網路時，您必須對不同的 802.11 訊框類型有充分理解，以此為基礎尋找可辨識出 WLAN 網路問題區域成因的指標。使用 OmniPeek 或 Wireshark 這類工具進行 WLAN 監聽器追蹤時，您可以監控無線電網路介面卡 (NIC) 與存取點之間的通訊。您必須瞭解無線 LAN 運作過程中會出現的每種訊框類型，並解決網路問題。 在 WLAN RF 環境中，無線傳輸條件會動態改變，使得在 WLAN 中進行協調變成一個很大的問題。 管理與控制封包就是專門用來執行這些協調功能。

若要在 RF 環境相關的 WLAN 網路中找到發生 WLAN 問題的原因，最好使用不具備任何安全機制的開放式驗證方法來測試 WLAN 網路。採用這種方法時，RF 連線問題就會浮現，您可在改用更強的加密機制並移至更高的 OSI 層之前加以修正。 在 802.11 規格中進行驗證是以驗證無線站台或裝置為基礎，不是以驗證使用者為基礎。

根據 802.11 規格，用戶端驗證程序包含以下交易。

1. 存取點持續傳送信標訊框，由附近的 WLAN 用戶端接收。

2. 用戶端也可以在每個頻道上的自有探查請求訊框進行廣播.

3. 範圍內的存取點會以探查請求訊框回應.

4. 用戶端會判斷哪一個存取點 (AP) 最能存取並傳送驗證請求.

5. 存取點傳送驗證回覆。

6. 成功驗證後，用戶端就能將相關請求訊框傳送至存取點。

7. 存取點以關聯回應回覆。

8. 用戶端現在就能夠將流量傳送至存取點.

802.11 用戶端驗證程序

在 802.11 MAC 第 2 層中進行無線通訊時，使用的訊框有 3 種類型，可用於管理和控制無線連結。

這些類型是管理訊框、控制訊框與資料訊框。您可詳細瞭解這些訊框的組成，在使用 WLAN 監聽器追蹤時有助於更妥善分析 WLAN 問題。

管理訊框

802.11 管理訊框可讓站台建立通訊並加以維持。 我們會使用管理封包來支援驗證、關聯性與同步。

以下是常見的 802.11 管理訊框子類型：

- 驗證訊框：這種訊框可在 WLAN 拓撲中發出驗證網路身分的請求。在 802.11 驗證程序中，存取點可決定接受或拒絕無線電 NIC 身分識別建立資源的請求。 「驗證」會限制網路上傳送與接收的能力。這也是裝置嘗試連線至 802.11 WLAN 的第一步。 這個功能是透過交換管理封包來處理。「驗證」則是透過要求/回應交換管理封包來處理。 交換的封包數量是根據採用的驗證方式而定。

wlan.fc.type_subtype == 0x0b

NIC 開始進行此程序時，會將包含其身分識別的驗證訊框傳送至存取點。 透過開放式系統驗證（預設），無線 NIC 只會傳送一個驗證訊框，存取點會回應驗證訊框，作為表示接受（或拒絕）的回應。此時會出現相關聯的驗證 ID，表示在加入網路時自行進行驗證的目前站台名稱。

- 取消驗證訊框：如果站台想要終止安全通訊，這就是站台將取消驗證訊框傳送給其他站台時所使用的宣告封包。 這是來自驗證站台（BSS 或同等功能) 的單向通訊，必須接收， 且會立即生效。

wlan.fc.type_subtype == 0x0c

- 關聯請求訊框：802.11 關聯可讓存取點針對無線電 NIC 配置資源並進行同步。 NIC 開始關聯程序時，會將關聯請求傳送至存取點。這個訊框承載著 NIC 相關資訊（例如支援的資料傳輸速率）以及想要建立關聯的網路 SSID。 接收關聯請求後，存取點會考量與 NIC 的關聯，然後（如果接收的話）保留記憶體空間，並針對 NIC 建立關聯 ID。 封包可以顯示傳送者目前的關聯。 關聯與重新連接均透過請求/回應管理封包來處理。

wlan.fc.type_subtype == 0x0

- 關聯回應訊框：存取點會將包含接受或拒絕通知的關聯回應訊框，傳送至請求關聯的無線電 NIC，且會納入請求者的關聯 ID。 若存取點接收無線射頻 NIC，訊框會包含與關聯相關的資訊，例如關聯 ID 與支援的資料傳輸速率。若接受關聯請求，無線電 NIC 就能使用存取點與網路和存取點分佈端系統上的其他 NIC 進行通訊。

wlan.fc.type_subtype == 0x01

- 重新關聯請求訊框：這個訊框與關聯請求類似，但目的不同，主要是在用戶端漫遊時最實用。若無線電 NIC 漫遊範圍超出目前關聯的存取點，且發現另一個存取點有更強的信標訊號，則無線電 NIC 會向新的存取點傳送重新關聯訊框。接著，新的存取點會進行協調，將先前存取點緩衝區中等待傳輸的資料訊框轉送至無線電 NIC。 傳送者必須完成驗證，才能成功取得關聯。

wlan.fc.type_subtype == 0x02

- 重新關聯回應訊框：存取點會將包含接受或拒絕通知的重新關聯回應訊框，傳送至請求重新關聯的無線電 NIC。 訊框與關聯程序類似，會包含與關聯相關的資訊，例如關聯 ID 與支援的資料傳輸速率。

- 解除關聯訊框：若站台想終止與其他站台的關聯，就會向該站台傳送解除關聯訊框。 例如，正常關閉的無線 NIC 可以傳送解除關聯訊框，以警示存取點該 NIC 已經關閉。 接著，存取點就可以放棄記憶體配置，並將無線 NIC 從關聯表格中移除。 存取點或裝置都可以簡單宣告解除關聯。

用於應用和僅查詢解除關聯資料包的過濾器是wlan.fc.type_subtype == 0x0a。

- 信標幀：存取點定期傳送信標幀來通告其存在和中繼資訊，如時間戳，以幫助成員站與BSS、SSID以及與存取點相關的在範圍內的無線NIC的其它引數同步。此訊框的目的是宣告非競爭週期 (CF) 開始，在此週期內，存取點會藉由輪詢來授予傳輸權限。無線電NIC會持續掃描所有802.11無線電頻道並收聽信標，藉此選擇與哪個存取點具有最佳訊號與可用性建立關聯。

用於應用和僅查詢信標資料包的過濾器是wlan.fc.type_subtype == 0x08。

- 探查請求訊框：某個站台或用戶端變為使用中，或 PC 上的 WLAN 卡變為使用中後，若需要從其他站台或存取點取得資訊，就會傳送探查請求訊框。無線電 NIC 送出探查請求以判斷哪一個存取點位於範圍內後，會在用戶端支援的每個頻道傳送探查請求訊框，嘗試尋找範圍內符合 SSID 與用戶端請求資料傳輸速率的所有存取點。用戶端會評估各種因素（如支援的資料傳輸速率與存取點負載），判斷要與哪個存取點建立關聯，藉此選出最佳存取點。從 APS 取得探查回應的回應結果後，就會進入 802.11 網路驗證階段。支援這種機制也有助於漫遊站台在不同基地台間移動，在維持連線的情況下，繼續搜尋新的存取點。

用於應用和僅查詢探測請求資料包的過濾器是wlan.fc.type_subtype ==0x04。

- 探查回應訊框：為回應探查請求，符合條件的 APS 會以探查回應訊框回應，其中包含同步資訊與存取點負載，可能也會含有功能資訊、支援的資料傳輸速率等內容。

用於應用和僅查詢探測請求資料包的過濾器是wlan.fc.type_subtype ==0x05。

控制訊框

802.11 控制訊框會在站台間傳遞資料訊框時提供協助。常見的 802.11 控制訊框子類型如下：

- 請求傳送 (RTS) 訊框：RTS/CTS 是選用功能，當多個隱藏的站台與同一存取點建立關聯時，能減少出現訊框衝突的情況。 某個站台會將 RTS 訊框傳送到另一個站台，作為傳送資料訊框前必要的雙向交握第一階段。

wlan.fc.type_subtype == 0x1B

- 確認 (ACK) 訊框：接收站台收到資料訊框後，會透過錯誤檢查程序來偵測是否有錯誤存在。如果沒有找到錯誤，接收站台就會將 ACK 訊框傳至傳送站台。如果傳送站在一段時間後未收到ACK，則傳送站可以重新傳輸幀。

wlan.fc.type_subtype == 0x1D

資料訊框

行動站台與存取點之間建立基本 WLAN 通訊後，才會出現這類資料訊框。分析時一律使用 802.11 資料訊框，一般是為了以無線方式驗證及分析通訊協定及訊框本體內來自較高層的資料是否通過線路。這些訊框會從本體內部傳輸較高層的資料封包，例如網頁、印表機控制資料等。

wlan.fc.type_subtype == 0x20

在封包分析器中，您可以觀察 802.11 資料訊框中的訊框本體內容，以瞭解所關注的流量。

參考資料

- IEEE 802.11 精簡版參考指南

- 思科支援論壇

- Cisco Secure Access

802.11 監聽器擷取分析 — 具備 PSK 或 EAP 的 WPA/WPA2

WPA-PSK (TKIP)

1.會定期傳輸信標訊框，以宣告無線網路的存在，並包含網路的所有相關資訊（資料速率、通道、安全密碼、金鑰管理等）：

2.STA 會傳送探查請求，從 AP 取得資訊：

3.探查回應。收到 STA 的探查回應後，AP 會利用探查回應訊框來回應，訊框中包含功能資訊、支援的資料傳輸速率等內容：

透過 4.802.11 驗證程序，存取點可決定是否接收或拒絕無線電 NIC 身分識別。程序一開始，NIC 會將包含其身分識別的驗證訊框傳送給存取點。使用開放系統驗證（預設）時，無線電NIC只會傳送一個驗證訊框，而存取點會以驗證訊框作為回應，表示接受（或拒絕）。：

a.Dot11身份驗證請求：

b.Dot11身份驗證響應：

5. 802.11 關聯可讓存取點針對無線電 NIC 配置資源並進行同步。 NIC 開始關聯程序時，會將關聯請求傳送至存取點。這個訊框承載著 NIC 相關資訊（例如支援的資料傳輸速率）以及想要建立關聯的網路 SSID。

a.Dot11關聯請求：

接收關聯請求後，存取點會考量與 NIC 的關聯，然後（如果接收的話）保留記憶體空間，並針對 NIC 建立關聯 ID。

b.Dott11關聯響應：

6.四向式交握。此階段會建立 PTK，作為建構以下值所用的 PMK：

a.AP傳送具有ANonce的802.1x身份驗證幀。此時 STA 已具有建構 PTK 所需的所有資訊：

b.STA以802.1x驗證幀回應，其中SNonce和MIC：

c. AP 會以包含序號的新 MIC 與 GTK 建構 802.1x 訊框， 這個序號後續會在下一個多點傳送或廣播訊框中使用，讓接收 STA 可以執行基本重播偵測：

d.STA傳送ACK：

從該點傳送的所有資料都已經加密。

WPA2-PSK (AES/TKIP)

這個程序與前一節大同小異，只有不同的資訊才會反白顯示。

1.WPA2 AP管理幀包括RSN元素，包括單播加密套件、AKM資訊和GTK加密套件（如果同時選擇AES和TKIP，則可以對GTK使用強度較低的加密方法）。

2.在四次握手期間，幀在「型別」欄位中包含WPA2的版本資訊。

附註：若在追蹤中納入四向式交握金鑰交換訊框，且已知 PSK，您就可以解密以 WEP/WPA-PSK/WPA2-PSK 加密的無線流量。

若要在 Wireshark 中加密無線流量，請依序前往偏好設定 > 通訊協定 > IEEE 802.11，然後提供 PSK 資訊，並選取啟用解密選項。

如要解密格式中的 WPA/WPA2 已加密流量特定金鑰：

wpa-psk:PSK:SSI

附註：若要從 Wireshark 的特定 STA 中篩選掉 WLAN 流量，可使用WLAN 統計資料選項。

要過濾來自特定STA的流量，請導航到Statistics > WLAN Traffic。 在 SSID 清單中選取與 STA 相關聯的對應 SSID，然後根據 STA 套用篩選條件。

如何使用Wireshark解密無線資料包捕獲上的WPA2 AES資料

要求:

1. 擷取檔案為 .pcap 格式。

2. 訊框會以 802.11 格式呈現。

3. 知道 SSID 名稱與 WLAN 的 PSK 是從哪一次的無線擷取中收集而來。

4. 金鑰：擷取 4 EAPOL 四向式交握。

要執行此操作，最準確的過程是啟動捕獲，然後取消對客戶端的身份驗證，以便從零捕獲進程，這意味著可以包括4向EAPOL握手。

如果幀使用其他格式（如PEEKREMOTE），則可能需要對幀進行解碼，請參閱如何解碼PEEKREMOTE幀部分。

程序

在 Wireshark 中開啟擷取檔案後，請依序前往編輯 > 偏好設定選單。

前往通訊協定選單尋找 IEEE 802.11。

在「IEEE 802.11」區段中勾選啟用解密選取方塊，然後按一下解密金鑰標籤旁的編輯... 按鈕。

進入編輯選單後，按一下視窗左側的新增按鈕。

在金鑰類型中選擇 wpa-psk。

若要取得金鑰，您必須知道執行加密程序時使用的 SSID 確切名稱與 PSK。

取得這兩項值後，即可前往下一個網站根據這兩項元素產生金鑰。

- WPA PSK (原始金鑰) 產生器

在指定欄位中輸入 SSID 名稱與 PSK。您在欄位中輸入的字串必須與定義的 SSID 與 PSK 完全一致。

定義值後，按一下產生 PSK。複製系統產生的金鑰，然後返回 Wireshark。

將產生的金鑰貼到金鑰欄位。按一下「OK」（確定）。

接著，在偏好設定畫面中按一下套用。擷取檔案會隨即開始解碼。

解碼完成後，您就能看到先前加密的 802.11 封包內容。

WPA/WPA2 Enterprise

1. WPA(TKIP)/WPA2(AES) 搭配 dot1x (PEAP)

這個程序的步驟與先前一樣，但不包含 AKM 方法，也沒有 802.11 管理訊框中的 PTK/GTK 與 AP 通告屬性。

1. 在此範例中，AP 會通告使用 dot1x 驗證的 WPA (TKIP)/WPA2 (AES)。AKM 的 RSN 與 WPA 標籤屬性均包含 WPA 值，無論是否進行 PSK 驗證，此欄位都會包含 PSK。此外，這個範例針對 WPA 使用 TKIP，並針對 WPA2 使用 AES。

b.  STA 會選擇其中一種驗證方法，以及由 AP 通告的加密套件。此案例中選取了採用 AES 的 WPA2，這可以從 RSN IE 參數看出。

c.  成功建立 dot11 關聯後，系統會開始執行 dot1x 驗證。在此過程中，您可以看出 STA 使用什麼 EAP 方法來進行驗證，以及在要求者與 AAA 伺服器間進行憑證交換的資訊。

d.在成功執行dot1x身份驗證後，PMK在來自AAA伺服器的Access-Accept消息中傳輸到AP，並在客戶端上派生相同的PMK。接著會執行四向式交握，並建立 PTK 與 GTK。

在 WLC 與 AAA 伺服器間進行 Radius 交換：

一般流量圖表：

具備 dot1x (EAP-TLS) 的 WPA (TKIP)/WPA2 (AES)

相較於之前的驗證類型，這種驗證類型的不同之處在於用戶端會在「用戶端 Hello」訊息中提供其憑證，然後根據憑證在用戶端與 AAA 伺服器之間執行雙向驗證。

在 STA 與 WLC 之間交換 EAP：

在 WLC 與 AAA 伺服器間進行 Radius 交換：

一般流量圖表：

2. WPA(TKIP)/WPA2(AES) 搭配 dot1x (FAST)

與前一個範例相比，只有 dot1x 驗證階段會有些許不同。成功建立 dot11 關聯並執行 dot1x 驗證後，AP 會將 dot1x 身分識別請求傳送至 STA，然後 STA 會提供身分識別回應。回應內容取決於所使用的 PAC 佈建（頻內 PAC 佈建（階段 0）或頻外 PAC 佈建）。若使用頻內 PAC 佈建，PAC 會從 AAA 伺服器傳送至用戶端。用戶端取得 PAC 後，就會進入 EAP-FAST 階段 1，由此開始建立 TLS 通道（階段 1）。

建立 TLS 通道後，內部驗證方法（階段 2）就會在加密通道內啟動。成功驗證後，包含 PMK 的「Access-Accept」訊息就會從 AAA 伺服器傳送至 AP。系統會根據 STA 上的 dot1x 交換衍生相同的金鑰。此金鑰(PMK)用於計算4次握手期間的PTK，可用於保護STA和AP之間的通訊。

一般流量圖表：

802.11 監聽器擷取分析 — 多點傳送

簡介

多點傳送監聽

解決方案

控制器會以兩種模式執行多點傳送：

- 單點傳播模式：在此模式下，控制器會將每個多點傳送封包單點傳播到與控制器關聯的每個 AP。此模式效率低下，但不支援多點傳送的網路可能必須使用此模式。

- 多點傳送模式：在此模式下，控制器會將多點傳送封包傳送至 LWAPP 多點傳送群組。此方法會降低控制器處理器的額外負荷，並將封包複寫工作轉移到網路上，效率比單點傳播高出許多。

- 您可啟用使用控制器 GUI 或 CLI 的多點傳送模式。

WLC 上的 IGMP 偵聽

控制器軟體 4.2 版引入 IGMP 偵聽功能，可更有效地多點傳送封包。此功能啟用後，控制器會向用戶端收集 IGMP 報告，檢查第 3 層多點傳送位址和 VLAN 編號後，會從 IGMP 報告建立不重複的多點傳送群組 ID (MGID)，並將 IGMP 報告傳送至基礎架構交換器。控制器會使用與來源用戶端介面位址相同的來源位址傳送這些報告，

接著透過用戶端 MAC 位址更新 AP 上的存取點 MGID 表。當控制器收到特定多點傳送群組的多點傳送流量，會將流量轉送至所有 AP。不過，只有當 AP 有使用中的用戶端接聽或訂閱該多點傳送群組，才會傳送該特定 WLAN 上的多點傳送流量。系統會連同 MGID 轉送 IP 封包，此 MGID 是輸入 VLAN 的不重複識別碼，且為目的地多點傳送群組。系統會連同 MGID 轉送第 2 層多點傳送封包，此 MGID 是輸入介面上的不重複識別碼。

附註：2000 系列控制器、2100 系列控制器、思科整合式服務路由器的思科無線 LAN 控制器網路模組均不支援 IGMP 偵聽功能。

使用多點傳送模式的指導原則

請依循以下指導原則，在網路上啟用多點傳送模式：

思科整合式無線網路解決方案會針對特定目的使用部分 IP 位址範圍，設定多點傳送群組時，請記住這些範圍。雖然非建議做法，不過任何多點傳送位址都可以指派給 LWAPP 多點傳送群組，包含 OSPF、EIGRP、PIM、HSRP 和其他多點傳送通訊協定的保留連結本機多點傳送位址。

思科建議從管理範圍區塊 239/8 指派多點傳送位址。IANA 已經保留 239.0.0.0-239.255.255.255 的範圍，作為管理範圍位址，以便在私有多點傳送網域中使用。其他限制請參閱附註。這些位址本質上類似於保留私有 IP 單點傳播範圍，例如 RFC 1918 中定義的 10.0.0.0/8。網路管理員可在其網域內任意使用此範圍內的多點傳送位址，不用擔心與網際網路上的其他位址衝突。這個管理或私有位址空間必須在企業內部使用，且遭自治網域 (AS) 封鎖無法進出。

附註：請勿使用 239.0.0.x 或 239.128.0.x 位址範圍。這些範圍內的位址與連結本機 MAC 位址重疊，即使開啟 IGMP 偵聽功能，還是會淹沒所有交換器連接埠。

思科建議企業網路管理員在企業網路內進一步將此位址範圍切分為更小的地理管理範圍，以限制特定多點傳送應用程式的範圍。這麼做可防止高傳輸速率多點傳送流量離開頻寬充足的園區，導致 WAN 連結壅塞，同時也可有效率地篩選掉高頻寬多點傳送，防止其抵達控制器和無線網路。

在控制器上啟用多點傳送模式時，必須在控制器上設定 LWAPP 多點傳送群組。AP 會使用網際網路群組管理協定 (IGMP) 訂閱 LWAPP 多點傳送群組。

- Cisco 1100、1130、1200、1230 和 1240 系列 AP 可使用 IGMP 1、 2 和 3 等版本，但 Cisco 1000 系列 AP 只能使用 IGMP v1 加入多點傳送群組。

- 多點傳送模式只能在第 3 層 LWAPP 模式中運作。

- 處於監控模式、監聽器模式或惡意偵測器模式的 AP 不會加入 LWAPP 多點傳送群組位址。

- 若您使用搭載 4.1 以下版本的控制器，可在所有控制器上使用相同的多點傳送位址。若您使用搭載 4.2 以上版本的控制器，則須針對網路上使用的每個控制器，設定不同的 LWAPP 多點傳送群組。

- 若您使用 4.1 以下版本的控制器，多點傳送模式不會在子網路之間跨多個行動化事件運作，例如訪客通道、站台專用 VLAN，或使用 RADIUS 覆寫的介面。若在有線 LAN 上停用第 2 層 IGMP 偵聽/CGMP 功能，多點傳送模式就可用於這類子網路行動化事件。

在 4.2 以上版本中，多點傳送模式不能在子網路之間跨多個行動化事件（例如訪客通道）運作，但可透過使用 RADIUS 覆寫介面（僅限啟用 IGMP 偵聽的狀態下）和站台專用 VLAN（存取點群組 VLAN）運作。

- 控制器會捨棄傳送至 12222、12223 與 12224 號 UDP 連接埠的任何多點傳送封包。務必確認網路上的多點傳送應用程式並未使用這些連接埠號碼。

- 在 802.11a 網路中，多點傳送流量會以 6 Mbps 傳輸，因此如果有多個 WLAN 嘗試以 1.5 Mbps 傳輸，封包就會遺失，這會中斷多點傳送工作階段。

設定多點傳送（使用「多點傳送 — 多點傳送」模式）

選擇Mutlicast - Multicast並配置組，移動組中的每個WLC可以使用唯一的地址。

在 L3 裝置上啟用多點傳送路由，並在以下 VLAN 上啟用 PIM：  管理、AP 管理員、AP 所在的 VLAN，以及用戶端會接收多點傳送資料流的 VLAN。

範例：

VLAN 40 即為 WLC 管理；VLAN 40 是供 AP 使用，而 VLAN 50 則是用戶端所在位置。因此，在所有這些SVI下，您需要發出組播命令。

發出顯示所有多點傳送的命令以進行驗證，例如發出 show ip mroute、show ip igmp groups 命令以驗證針對 AP 建立的群組是否妥善建置。

您也可以在 WLC 上啟用 IGMP 偵聽。WLC 會針對接收的 IGMP 訊息保留自己的偵聽表，以瞭解提出資料流請求的來源。

在無線 LAN 控制器上

在 WLC 上啟用全域多點傳送，並在 WLC 上啟用「多點傳送 – 多點傳送」模式。

用戶端傳送加入多點傳送的訊息後，您就會在 WLC MGID 看到相關資訊。

有線網路上的多點傳送組態

設定全域多點傳送路由，然後在每個介面上啟用 PIM。

6504-WLCBUG#sh run | i multicast

ip multicast-routing

6504-WLCBUG#sh run int vla 50

Building configuration...

Current configuration : 119 bytes

！

interface Vlan50

description // WLAN DHCP pool VLAN //

ip address 172.16.1.1 255.255.255.0

ip pim dense-mode

end

6504-WLCBUG#sh run int vla 40

Building configuration...

Current configuration : 121 bytes

！

interface Vlan40

description // Management Vlan //

ip address 10.105.135.136 255.255.255.128

ip pim dense-mode

end

6504-WLCBUG#sh ip pim interface vlan 40

Address         Interface               Ver/   Nbr   Query DR

DR Mode   Count Intvl Prior

10.105.135.136   Vlan40                   v2/D   0     30     1     10.105.135.136

6504-WLCBUG#sh ip pim interface vlan 50

Address         Interface               Ver/   Nbr   Query DR     DR

Mode   Count Intvl Prior

172.16.1.1       Vlan50                   v2/D   0     30     1     172.16.1.1

6504-WLCBUG#sh ip mroute

IP 多點傳送路由表

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - 本機、P - 已剪除, R - RP 位元集、F - 註冊旗標、

T - SPT 位元集、J - 加入 SPT、M - MSDP 建立項目、

X - Proxy 加入執行中計時器、A - MSDP 通告候選、

U - URD、I - 已接收來源特定主機報告、

Z - 多點傳送通道、z - MDT 資料群組傳送者、

Y - 已加入 MDT 資料群組、y - 傳送至 MDT 資料群組

V - RD 與向量、v - 向量

Outgoing interface flags: H - Hardware switched, A - Assert winner

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.255), 4d17h/00:02:03, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

傳出介面清單：

Vlan40, Forward/Dense, 4d17h/00:00:00

(*, 239.254.0.3), 2w1d/00:02:07, RP 0.0.0.0, flags: DC

Incoming interface: Null, RPF nbr 0.0.0.0

傳出介面清單：

Vlan40, Forward/Dense, 3d10h/00:00:00

(*, 224.0.1.40), 2w1d/00:02:13, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0

傳出介面清單：

Vlan11, Forward/Dense, 2w1d/00:00:00

封包擷取

拓撲

Wired PC ----------- 6500 Switch -------- WISM ------- AP )))) ((((( Wireless Client

Vlan 50                       Vlan 40                   Vlan 40       Vlan 40             Vlan 50

MCAST 流量產生工具

用於有線連線的 PC，以產生「多點傳送資料流 – 持續 UDP」封包。

在 MCAST 產生器上擷取的有線 Wireshark 封包

在 MCAST 封包產生器上擷取的 Windows Netmon</h=5>

在無線用戶端上會使用 MCAST 接收工具，從來源（有線連線 PC）接收多點傳送流量。

Wireshark 在無線用戶端的無線介面上進行擷取

Netmon 在無線用戶端的無線介面上進行擷取

802.11 監聽器擷取分析 — Web 驗證

簡介

Cisco WLC 疑難排解時的 Web 驗證監聽器

Web 驗證程序

Web 驗證是第 3 層安全功能，會導致控制器不允許來自特定用戶端的 IP 流量（DHCP 相關封包/DNS 相關封包除外），直到該用戶端正確提供有效的使用者名稱和密碼為止，透過預先驗證 ACL 所允許的流量例外。Web 驗證是唯一允許用戶端在驗證前取得 IP 位址的安全原則。這是一種簡單的驗證方法，無需借助要求者或用戶端公用程式。Web 驗證可在本機的 WLC 上完成，也可以透過 RADIUS 伺服器進行。部署供訪客存取的網路時，通常都會採用 Web 驗證。

當控制器攔截到用戶端傳來的第一個 TCP HTTP (port 80) GET 封包，就會開始執行 Web 驗證。若要讓用戶端的網頁瀏覽器進到這個階段，用戶端必須先取得 IP 位址，並為網頁瀏覽器將 URL 轉譯為 IP 位址（DNS 解析）。如此一來，網頁瀏覽器就知道要將 HTTP GET 傳送到哪個 IP 位址。

若在 WLAN 上設定 Web 驗證，控制器會在驗證程序完成前封鎖來自用戶端的所有流量（DHCP 和 DNS 流量除外）。當用戶端將第一個 HTTP GET 傳送至 TCP 連接埠 80，控制器會將用戶端重新導向至 https://10.10.10.1/ 來處理。此程序結束後，登入網頁會隨即出現。

- 開啟網頁瀏覽器並輸入 URL，例如 http://www.google.com。  用戶端會為此 URL 送出 DNS 請求，以取得目的地 IP。WLC 會略過傳至 DNS 伺服器的 DNS 請求，而 DNS 伺服器會以包含目的地 (http://www.google.com) IP 位址的 DNS 回覆來回應，此資訊最後會轉送至無線用戶端

- 接著，用戶端會嘗試啟動與目的地 IP 位址之間的 TCP 連線。用戶端會以 http://www.google.com 的 IP 位址為目的地，送出 TCP SYN 封包。

- WLC 已針對用戶端設定規則，因此可當成 http://www.google.com 的 Proxy 使用。這會以 http://www.google.com 的 IP 位址為來源，將 TCP SYN-ACK 封包送回用戶端，而用戶端會傳回 TCP ACK 封包，以完成三向式 TCP 交握並完整建立 TCP 連線。

- 用戶端會將 HTTP GET 封包傳送至 http://www.google.com。WLC 攔截到此封包後，會將它傳送以進行重新導向處理。HTTP 應用程式閘道會準備 HTML 本文並傳回，以回覆用戶端請求的 HTTP GET。此 HTML 會引導用戶端前往 WLC 的預設網頁 URL，例如 <Virtual-Server-IP>/login.html。

- 用戶端關閉與 IP 位址（例如 http://www.google.com）之間的 TCP 連線。

- 此時用戶端會前往 http://10.10.10.1/login.html，並嘗試啟動與 WLC 虛擬 IP 位址之間的 TCP 連線，將 10.10.10.1 的 TCP SYN 封包傳送至 WLC。

- WLC 會以 TCP SYN-ACK 回應，用戶端則會向 WLC 傳回 TCP ACK 以完成交握。

- 用戶端將 /login.html 的 HTTP GET 傳送至 10.10.10.1，以請求登入頁面。

- 此請求最高可傳送至 WLC 的 Web 伺服器，伺服器會以預設登入頁面回應。用戶端會在瀏覽器視窗中收到登入頁面，使用者可在此登入。

組態 Webauth

請動手設定。

拓撲

無線用戶端連線至在 WLC 上註冊的 AP。該 WLC 連線至交換器，而交換器連線至設定 DNS、路由、L3 連線的路由器。

將路由器作為 DNS 使用。

3825#sh run | i host

hostname 3825

ip host www.google.com 192.168.200.1

ip host www.yahoo.com 192.168.200.200.2

ip host www.facebook.com 192.168.200.200.3

3825#sh run | i dns

dns-server 172.16.16.1

ip dns server

3825#sh run | b dhcp

ip dhcp excluded-address 172.16.16.1 172.16.16.5

!

ip dhcp pool webauth-sniffer

network 172.16.16.0 172.16.255.0

default-router 172.16.16.1

dns-server 172.16.16.1

WLCC 設定

- 前往 WLAN，然後按一下新增輸入詳細資料。

- 針對 NO L2 驗證設定 WLAN。

- 針對使用 WEBAUTH 的 L3 驗證設定 WLAN。

- 配置後，您可以看到如下所示的內容。

- 前往安全性索引標籤，建立本機網路使用者。

- 輸入用戶端認證。

- 依序前往安全性 > Webauth 索引標籤，並選擇 Web auth type ==Internal / External redirect / Custom。

- 與用戶端連線。

- 取得 IP 位址後，開啟瀏覽器並輸入網址。

- 這會將用戶端重新導向 Web 驗證頁面，請在此輸入使用者名稱與密碼。

- 成功登入後，系統會將用戶端重新導向至「重新導向」頁面。

以下是用戶端嘗試連線時的封包擷取內容。

用戶端取得：

- DHCP

- DNS

- WTTP

用戶端 IP 位址為 172.16.16.7。用戶端將存取的 Web 伺服器 URL 解析為 192.168.200.1。如您所見，用戶端進行三向式交握來啟動 TCP 連線，然後傳送以封包 576 開頭的 HTTP GET 封包。控制器攔截封包，然後以代碼 200 回覆。代碼 200 封包內有一個重新導向 URL：

用戶端進入 HTTPS 登入頁面

用戶端接受憑證

接著，用戶端啟動與重新導向 URL 的 HTTPS 連線，將其傳送至 10.10.10.1，也就是控制器的虛擬 IP 位址。用戶端必須驗證伺服器憑證，或是忽略憑證以顯示 SSL 通道。這裡可以看到，顯示驗證成功且 TCP 工作階段順利啟動後，用戶端嘗試存取 Facebook.com。

以下是客戶端嘗試連線時的客戶端調試

Cisco Controller) >

(Cisco Controller) >show debug

MAC address ................................ 00:21:5c:8c:c7:61

Debug Flags Enabled:

dhcp packet enabled.

dot11 mobile enabled.

dot11 state enabled

dot1x events enabled.

dot1x states enabled.

pem events enabled.

pem state enabled.

CCKM client debug enabled.

webauth redirect enabled.

May 18 13:43:50.568: 00:21:5c:8c:c7:61 Adding mobile on LWAPP AP a8:b1:d4:c4:35:b0(0)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Association received from mobile on AP a8:b1:d4:c4:35:b0

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Changing ACL 'MNGMNT' (ACL ID 0) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:1633)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Applying site-specific IPv6 override for station 00:21:5c:8c:c7:61 - vapId 1, site 'default-group', interface 'webauth-sniffer'

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Applying IPv6 Interface Policy for station 00:21:5c:8c:c7:61 - vlan 300, interface id 4, interface 'webauth-sniffer'

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 STA - rates (8): 130 132 139 150 12 18 24 36 0 0 0 0 0 0 0 0

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 STA - rates (12): 130 132 139 150 12 18 24 36 48 72 96 108 0 0 0 0

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Initializing policy

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Change state to AUTHCHECK (2) last state AUTHCHECK (2)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 AUTHCHECK (2) Change state to L2AUTHCOMPLETE (4) last state L2AUTHCOMPLETE (4)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) DHCP Not required on AP a8:b1:d4:c4:35:b0 vapId 1 apVapId 1for this client

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Not Using WMM Compliance code qosCap 00

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP a8:b1:d4:c4:35:b0 vapId 1 apVapId 1

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state DHCP_REQD (7)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 apfMsAssoStateInc

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 apfPemAddUser2 (apf_policy.c:223) Changing state for mobile 00:21:5c:8c:c7:61 on AP a8:b1:d4:c4:35:b0 from Idle to Associated

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Scheduling deletion of Mobile Station: (callerId: 49) in 1800 seconds

*apfMsConnTask_0: May 18 13:43:50.569: 00:21:5c:8c:c7:61 Sending Assoc Response to station on BSSID a8:b1:d4:c4:35:b0 (status 0) ApVapId 1 Slot 0

*apfMsConnTask_0: May 18 13:43:50.569: 00:21:5c:8c:c7:61 apfProcessAssocReq (apf_80211.c:5272) Changing state for mobile 00:21:5c:8c:c7:61 on AP a8:b1:d4:c4:35:b0 from Associated to Associated

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 4494, Adding TMP rule

*apfReceiveTask: May 18 13:26:46.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule

type = Airespace AP - Learn IP address

on AP a8:b1:d4:c4:35:b0, slot 0, interface = 1, QOS = 0

ACL Id = 255, Jumbo Fr

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 1506 IPv6 Vlan = 300, IPv6 intf id = 4

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (ACL ID 255)

*pemReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0

*pemReceiveTask: May 18 13:43:50.571: 00:21:5c:8c:c7:61 Sent an XID frame

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP received op BOOTREQUEST (1) (len 310,vlan 0, port 1, encap 0xec03)

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP processing DHCP DISCOVER (1)

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP requested ip: 192.168.226.44

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to DS

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP received op BOOTREPLY (2) (len 308,vlan 300, port 1, encap 0xec00)

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP processing DHCP OFFER (2)

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 172.16.16.7

*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1

*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to STA

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP received op BOOTREQUEST (1) (len 314,vlan 0, port 1, encap 0xec03)

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP processing DHCP REQUEST (3)

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP requested ip: 172.16.16.7

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to DS

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP received op BOOTREPLY (2) (len 308,vlan 300, port 1, encap 0xec00)

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP processing DHCP ACK (5)

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 172.16.16.7

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 Static IP client associated to interface webauth-sniffer which can support client subnet.

*DHCP Socket Task: May 18 13:43:50.708: 00:21:5c:8c:c7:61 Adding Web RuleID 22 for mobile 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.708: 00:21:5c:8c:c7:61 172.16.16.7 DHCP_REQD (7) Change state to WEBAUTH_REQD (8) last state WEBAUTH_REQD (8)

*apfMsConnTask_0: May 18 13:44:43.347: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 1506 IPv6 Vlan = 300, IPv6 intf id = 4

*apfMsConnTask_0: May 18 13:44:43.347: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Successfully plumbed mobile rule (ACL ID 255)

(Cisco Controller) >*emWeb: May 18 13:47:39.321: 00:21:5c:8c:c7:61 Username entry (Cisco) created for mobile, length = 5

*emWeb: May 18 13:47:39.321: 00:21:5c:8c:c7:61 Username entry (Cisco) created in mscb for mobile, length = 5

*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Change state to WEBAUTH_NOL3SEC (14) last state WEBAUTH_NOL3SEC (14)

*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 apfMsRunStateInc

*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_NOL3SEC (14) Change state to RUN (20) last state RUN (20)

*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 Session Timeout is 1800 - starting session timer for the mobile

參考資料：

- IEEE 802.11 標準

- 思科支援論壇參考資料

- 在 macbook 上收集擷取資料