某銀行無線網路頻繁掉線重認證分析、解決方案及抓包經驗分享

一、簡介 

在XXXX銀行網路運維服務專案中，遇到了多次客戶反映無線網路中斷需要多次重新認證才有可能再次連線到網路的故障現象；發生在XXXX等地點的類似故障，多為單個客戶、分散小範圍出現，未進入深層次分析；此次XXXX園區因大量開發測試人員搬入辦公，導致無線接入數量成“井噴”式增長，導致工作日上班高峰期間（約08：50-09:40）大面積集中式出現無線網路頻繁掉線需多次重認證才有可能登陸成功，影響到了正常辦公；

收集到大量重複相關日誌資訊如下

“

21 Mon Sep 7 09:06:36 2015 RADIUS server 10.102.64.51:1812 failed to respond to request (ID 128) for client 3c:a9:f4:81:5b:2c / user `unknown`

22 Mon Sep 7 09:06:35 2015 RADIUS server 10.103.64.51:1812 failed to respond to request (ID 51) for client 28:b2:bd:b7:01:42 / user `unknown`

*Sep 15 10:03:58.928: %DOT1X-4-INVALID_MSG_TYPE: authlib.c:85 Invalid message type 9 received from AAA

*Sep 15 10:03:58.478: %DHCP-4-LEASE_NOT_MATCH: dhcpd.c:307 Lease for 10.115.48.21 does not belong to34:02:86:4d:be:85.

*Sep 15 10:03:56.148: %DHCP-4-LEASE_NOT_OBTAINED: dhcpd.c:381 DHCP Lease could not be allocated to the client

*Sep 15 10:03:55.206: %DHCP-4-RELAY_SERVER_NOTGET: dhcp_proxy.c:2216 Unable to get the dhcp relay server`s ip address

*Sep 15 10:02:41.728: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (13) exceeded for client 28:e3:47:71:fc:bb

*Sep 15 10:02:41.727: %DOT1X-4-INVALID_MSG_TYPE: authlib.c:85 Invalid message type 9 received from AAA

*Sep 15 10:02:36.729: %DOT1X-4-INVALID_MSG_TYPE: authlib.c:85 Invalid message type 9 received from AAA

*Sep 15 10:02:31.727: %DOT1X-4-INVALID_MSG_TYPE: authlib.c:85 Invalid message type 9 received from AAA

”

由抓包及Debug輸出資訊Cisco TAC工程師分析如下：

“

在其他時間，我們看到的都是這樣的訊息：

5804: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 Adding mobile on LWAPP AP 00:3a:98:eb:4f:c0(0)    <————我們收到了客戶端傳送的probe資訊

5805: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 23) in 5 seconds <————我們開啟了5s超時，等待使用者發關聯請求

5806: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 apfProcessProbeReq (apf_80211.c:4722) Changing state for mobile e8:2a:ea:a0:b9:e1 on AP 00:3a:98:eb:4f:c0 from Idle to Probe

5806: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 apfProcessProbeReq (apf_80211.c:4722) Changing state for mobile e8:2a:ea:a0:b9:e1 on AP 00:3a:98:eb:4f:c0 from Idle to Probe

5808: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

5809: *Sep 17 09:04:51.747: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

5810: *Sep 17 09:04:51.747: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

5811: *Sep 17 09:04:51.747: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

5812: *Sep 17 09:04:56.701: e8:2a:ea:a0:b9:e1 apfMsExpireCallback (apf_ms.c:418) Expiring Mobile!   <———5s過後沒收到使用者關聯請求，這個使用者被清除。

5813: *Sep 17 09:04:56.701: e8:2a:ea:a0:b9:e1 0.0.0.0 START (0) Deleted mobile LWAPP rule on AP [00:3a:98:eb:4f:c0]  <———5s過後沒收到使用者關聯請求，這個使用者被清除。

5814: *Sep 17 09:04:56.701: e8:2a:ea:a0:b9:e1 Deleting mobile on AP 00:3a:98:eb:4f:c0(0)          

對比你那個成功的，你就能看到：

 

*Sep 17 09:06:50.267: e8:2a:ea:a0:b9:e1 Adding mobile on LWAPP AP 00:16:47:4d:7e:60(0)

*Sep 17 09:06:50.267: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 23) in 5 seconds

*Sep 17 09:06:50.267: e8:2a:ea:a0:b9:e1 apfProcessProbeReq (apf_80211.c:4722) Changing state for mobile e8:2a:ea:a0:b9:e1 on AP 00:16:47:4d:7e:60 from Idle to Probe

*Sep 17 09:06:50.267: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

*Sep 17 09:06:51.090: e8:2a:ea:a0:b9:e1 Association received from mobile on AP 00:16:c8:17:b8:e0  <————5s鍾內我們收到了使用者的關聯請求，這個使用者就開始關聯的各種狀態操作直至連線成功。

 

所以，從debug來看，有兩種可能：

 

1.      故障時刻客戶沒法association，這個就是客戶端側的問題了，WLC上無法控制和影響。您可以嘗試去升級下客戶端網路卡驅動，看看是不是客戶端側的一些已知問題。

2.      故障時刻客戶端發了association，但是WLC沒收到，比如通道太繁忙，空中報文丟失。但是從之前的資訊，如果你這個客戶端是在那個-08 AP （通道利用率80%），那有可能是這種現象，但是如果是在其他AP，通道利用率都很低，應該不會是這個原因。

 

另外從你的描述，重啟客戶端就能解決，這個更像是客戶端側當時有些問題。當然還有一個點也需要關注，你的客戶端相對較新，WLC和AP都比較老，l兩者的相容性可能不是最好，如果可能的話，可以嘗試拿一個2504，安裝幾個雙頻AP，在小範圍先做測試，看看是不是這個問題。

”

 

 

 

WLC收集DEBUG資訊命令：

 

Show run-config

Show msglog

Show traplog

Show ap auto-rf 802.11b <AP 名稱> 最好能包括故障區域當時的所有AP的情況以便我們瞭解故障時刻的通道擁擠程度。

 

Debug client e8:2a:ea:a0:b9:e1  << e8:2a:ea:a0:b9:e1為故障終端無線MAC；

debug aaa all enable

debug dot1x packet enable

debug disable-all  <<關閉WLC上DEBUG輸出；                       

二、故障現象緩解解決方案

***在無法及時升級無線網路硬體裝置條件下，提出緩解故障方案；

（以故障終端中存在較多的Wireless-N 7260無線網路卡為例，提出緩解解決方案）

1、  請優先在官網下載客戶終端無線網路卡的最新驅動程式!!!

(版本17.1.1501.01 Drive已顯示開始可以解決問題)（請提前告知IT服務檯，獲得管理員許可權！）

下載地址：https://downloadcenter.intel.com/zh-cn

  若依然效果不好，請依次進行以下嘗試；

2、請嘗試將終端802.11無線協議改為802.11g only；

[請儘量避免無線網路中終端單獨使用802.11b協議，作為802.11b的升級協議802.11g為相容802.11b將整體拉低無線網路的使用速率802.11b—-11Mbps（實際值為550～600kB/s）802.11g—-54Mbps，所以建議單獨使用速率較大的802.11g]

3、請嘗試將無線網路卡屬性中有關“支援U-APSD”選項禁用；

Unscheduled automatic power-save delivery，非排程自動節能傳送 ，802.11e-WLAN-Qos屬性。與某些型號AP互聯期間可能存在相容性問題，導致下行鏈路停止，從而減少RX資料吞吐量，建議禁用；

參考連結：

http://www.intel.com/support/cn/wireless/wlan/sb/cs-034875.htm

故障AP包括：

tp-link*TL-WA801N

Netgear*3700

等；

4、請嘗試將無線網路卡屬性中“2.4GHz 802.11n通道寬頻”調整為“20MHz”

11N預設使用頻寬是20M，和11BG一樣。考慮11BG，11個通道，1、6、11三個中心頻點。1通道佔據-1到3共計4個頻段，每個頻段5M，合計20M。6通道佔據4到8也是4個頻段計20M。11通道是一樣的，每個頻段都是5M。到了11N，開始支援40M頻寬。同理推一下，從-1開始要佔據8個頻段計40M頻寬。剩餘的頻寬只能再支援1個20M頻寬的通道了。很顯然，正交通道從BG的3個變成了11N的2個。就是說，在環境中，任意使用1和6通道的訊號都會干擾40M頻寬的通訊。總結起來就是40M頻寬吞吐量是20M的一倍，但環境中有干擾就不適宜選40M。總之，20MHZ的抗干擾能力強，如繞過障礙物等，40MHZ確實快點，但並不很穩定。 

以上具體操作內容根據Intel論壇，參考連結如下！

https://communities.intel.com/thread/47940?start=120&tstart=0

“

   802.11n channel width for band 2.4: 20 MHz.

   802.11n channel width for band 5.2: Auto (not in 20 MHz only)

   Fat channel intolerant: Disabled

   Roaming aggressiveness: Medium or less.

   Throughput enhancement: Disabled

   Transmit power: Highest

   Wireless mode: 802.11b/g

 

Also, try the following to disable other 802.11n and 802.11ac features:

 

   802.11n mode: Disabled

   HT mode: Disabled

   uAPSD: Disabled

 

In the wireless router, check the following options:

 

   Auto channel scan: Enable

   802.11 mode: Use 802.11g

Channel width: 20 MHz

                              ”

5、以實際無線環境中WLC為例，嘗試設定”Use 802.11g only”可通過在802.11b設定裡把802.11b的相關速率 1, 2, 5.5, 11Mbps 都disable，效果就等同禁用了802.11b；

   (通過禁用較低速率強制客戶使用高速率登入，雖然犧牲了無線有效覆蓋範圍，但實際相對優化了無線網路，對整體環境有利；)

6、實施後建議客戶若網路再次中斷可以嘗試點選行內安全軟體賽門鐵克進行“更新策略”或“重新驗證”操作，重新進行身份認證嘗試恢復連線，而不用重啟裝置花費時間；

三、無線診斷過程中相關無線抓包經驗分享

由CISCO TAC推薦《802.11 Wireless Sniffing (Packet Capture)》抓包文章；

https://supportforums.cisco.com/document/75331/80211-wireless-sniffing-packet-capture#Introduction

https://supportforums.cisco.com/document/100651/80211-sniffer-capture-analysis(額外參考文章)

文章中分享了“無線抓包基礎”“使用Mac(OS X10.6以上版本)進行無線抓包”“在Windows 7中使用Microsoft Network Monitor 3.4進行無線抓包”“使用瘦AP進行無線抓包”“基於Linux Live版本進行無線抓包”“使用OmniPeek Remote Assistant軟體診斷”彙總了各種環境下無線抓包方案；

本文章以“在Windows 7中使用Microsoft Network Monitor 3.4軟體進行無線抓包”為例進行無線抓包經驗分享；所需軟體下載地址如下：

 

Microsoft Network Monitor 3.4

[支援802.11a/b/g(部分支援11n)。Win7 64bit,需安裝NM34_x64.exe，安裝後需重啟]

http://www.microsoft.com/en-us/download/details.aspx?id=4865

[Microsoft Message Analyzer (Microsoft Network Monitor升級版本值得推薦)http://www.microsoft.com/en-us/download/details.aspx?id=44226 ]  

Wireshark (Wireshark 1.4.x版本無法讀取Netmon2檔案格式，建議使用1.5.x以上版本)

https://www.wireshark.org/#download

 

 

牢記注意事項：

①請將無線測試裝置靠近目標終端；②確認需要檢測的802.11協議、通道和頻寬③抓包期間保持“ WiFi Scanning Options”頁面開啟狀態,禁點[Close and Return to Local Mode]

1、 選擇所需網路卡；

2、 確定掃描協議及通道； 

抓包結束後，可以點選 [Stop] and use File -> Save as to save the .CAP file；儲存之後即可使用wirshark等軟體分析；

 

追加備註：

1、安裝Microsoft Network Monitor 3.4/Microsoft Message Analyzer 後，若無法顯示網路卡資訊，請嘗試重啟裝置；之後如果依然無法顯示網路卡資訊,可能是虛擬網路卡設定屬性問題，請嘗試在登錄檔(regedit.ext)中修改“MaxNumFilters”屬性，設定一個較大數值，例如“14”；

解決Netmon3.4安裝後無法顯示網路卡資訊，參考連結：

https://social.technet.microsoft.com/Forums/en-US/c5043fa7-691b-4b55-8630-57e734a98be8/network-monitor-34-wont-install-driver-on-nic-in-win7-x86?forum=netmon

2、針對使用較新的802.11ac無線網路卡的測試終端，可能需要確保無線網路卡設定中的“有線連線可用時禁用”的值為“啟用”，才能保障Netmon3.4/ Message Analyzer的正常使用；PS.預設即為“啟用”狀態，若同時使用有線和無線網路可設定“禁用”；

                         PPS.“不做死就不會死！”該屬性“坑”了我好久、好久、好久（重要的事情要說三遍！！！）…

 

 發現本支援社群中有類似帖子

“http://bbs.csc-china.com.cn/forum.php?mod=viewthread&tid=3872&highlight=%CE%DE%CF%DF%D7%A5%B0%FC”大家也可參考；

 最後吐槽下，如果有上傳附件功能直接上傳報告得了…害我一個個複製貼上…

特別提醒：

本文件為自行翻譯理解，能力有限不能保證絕對性。

如果您使用的是真實網路，請確保您已經瞭解所有命令的潛在影響。

轉載自小夥伴魚排飯的部落格

本文轉自Grodd51CTO部落格，原文連結：http://blog.51cto.com/juispan/2066396，如需轉載請自行聯絡原作者