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

一、簡介 

在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

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，如需轉載請自行聯系原作者