0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

基于Probe Request的主動掃描抓包交互流程

冬至子 ? 來源:通信之WLAN ? 作者:ChaserDtao ? 2023-05-30 16:39 ? 次閱讀

Beacon幀為周期間隔發(fā)送,雖大部分路由器將其間隔時間默認設置100ms(近似值),但路由器可以將其值配置更大。僅依賴“被動掃描”,WiFi設備在掃描過程中,存在漏掉發(fā)現(xiàn)周圍WiFi網(wǎng)絡的情況。因此,為了提高設備發(fā)現(xiàn)WiFi網(wǎng)絡的能力,有了基于Probe Request和Probe Response幀的“主動掃描”。本節(jié)接下來分析“主動掃描”。

好。下面我們看下“主動掃描”的抓包交互流程。

[場景1]:

  • WiFi設備在信道N上,發(fā)送Probe Request幀,其目的地址為廣播地址,稱為廣播幀。
  • 工作在信道N上的路由器,收到該廣播后,會響應Probe Response幀,其目的地址為單播地址,稱為單播幀。
  • WiFi設備收到Probe Response幀后,回復Ack確認,如下圖所示。

圖片

[場景2]:

  • WiFi設備在信道N上,發(fā)送Probe Request幀,其目的地址為單播地址,稱為單播幀。
  • 工作在信道N上,路由器的Mac地址為Probe Request幀中的目的地址,收到該Probe Request幀后,回復Ack確認,并回復Probe Response幀。
  • WiFi設備收到Probe Response幀后,回復Ack確認。如下圖所示。

圖片

通過以上可知,Probe Request幀可以被用作單播或廣播幀進行掃描請求。接下來我們就看“主動掃描”依賴Probe Request和Probe Response幀的格式內容。

Probe Request和Probe Response幀都為管理幀,符合管理幀通用定義格式:802.11 MAC Header + Frame Body + FCS,如下:

圖片

  • Probe request幀,子類型為4,可作為廣播幀或單播幀。做廣播幀時,Address3為廣播地址;做單播幀時,Address3為BSS對應的BSSID或一個單播接收地址。
  • Probe Response幀,子類型為5,作為單播幀響應WiFi設備。

802.11 MAC Header字段與Beacon幀一致,這里不再贅述,可參考【W(wǎng)iFi基礎學習到實在(五)】。

在開始討論Probe Request和Probe Response幀Body內容前,留個問題“WiFi設備每次連接WiFi網(wǎng)絡前,已掃描到該WiFi網(wǎng)絡,為什么還要通過發(fā)送Probe Request單播幀,做一次與路由器的交互呢?”

好,接下來我們探討抓包中Probe Request幀的Body內容,如下圖所示。

圖片

Probe Request幀Body內容只包含元素(Elements)。作為Probe Request幀,它的主要目的是觸發(fā)路由器給其回復Probe Response幀,發(fā)送的內容越短,占用信道資源越少,效率越高。因此,Probe Request幀只攜帶一些必要的內容信息。

[1]SSID Element:

表明掃描的目標網(wǎng)絡SSID。如Probe Request為廣播幀,隱藏網(wǎng)絡的網(wǎng)絡名稱與之相同,將會通過Probe Response回應。而網(wǎng)絡名稱不相同的網(wǎng)絡,則不回應。

注:

Probe Request為廣播,SSID Element字段長度為0或不包含SSID List element。則所有非隱藏網(wǎng)絡則收到后,回復Probe Response,隱藏網(wǎng)絡則不回應。

[2]Supported Rate和Extended Supported Rate Element:

表明掃描設備支持的速率集,路由器收到后,選擇其一種支持的速率發(fā)送Probe Response幀。

[3]DSPS Element:

表明當前Probe Request幀在那個信道上掃描發(fā)送。

[4]HT Capability Element:

表明WiFi設備支持802.11n,是一個HT設備。

注:

  • 如Probe Request幀中包含HE Capability Element,則表明WiFi設備支持802.11ax。
  • 作為請求幀,Probe Request幀Body可包含請求Element ID,如接收Probe Request幀的設備支持請求ID,則在回復的Probe Response幀Body中應攜帶該Element ID信息。
  • 實際WiFi設備使用中,為了盡可能掃描到周圍WiFi網(wǎng)絡,存在在一個信道上發(fā)送多個Probe Request幀。

注:協(xié)議規(guī)范【原文】

In an infrastructure BSS or in an IBSS, STAs receiving Probe Request frames shall respond with a probe response when the SSID in the probe request is the wildcard SSID or matches the specific SSID of the STA or when the specific SSID of the STA is included in the SSID List element.

以上Element詳細解釋可參考【W(wǎng)iFi基礎學習到實戰(zhàn)(六)】。

發(fā)送Probe Request幀,觸發(fā)接收者回復Probe Response幀,從中獲取當前WiFi網(wǎng)絡的信息能力。

接下來我們分析Probe Response幀的內容,如下圖所示Beacon幀和Probe Response幀的Body內容:

圖片

圖片

Probe Response幀Body內容分為:字段(Fields)和元素(Elements)。其Body內容和對應路由器發(fā)送的Beacon幀一致,Body內容解釋可參考【W(wǎng)iFi基礎學習到實戰(zhàn)(五-六)】。

這里我們分析下Probe Response幀Body內容可能存在與Beacon幀不同點。

  • Probe Response幀為單播幀,接收地址為單播地址。做為響應Probe Request幀,其Body可能攜帶Request幀中請求的Element ID信息。
  • Beacon幀為廣播幀,其Body中可能不攜帶Probe Request請求的Element ID信息。

Probe Response幀主要是將WiFi網(wǎng)絡的信息能力主動的反饋給請求設備。請求設備通過其Body內容了解當前WiFi網(wǎng)絡的狀態(tài)。

到這里,我們對Probe Request和Probe Response幀的探討就結束了,現(xiàn)在回到我們開始的問題“有些WiFi設備連接WiFi網(wǎng)絡前,已掃描到該WiFi網(wǎng)絡,為什么還要通過發(fā)送Probe Request單播幀,做一次與路由器的交互呢?”。

答:WiFi設備連接前做Probe Request請求,一是獲取當前WiFi網(wǎng)絡的加密方式,為接下來的認證關聯(lián)做準備;二是獲取WiFi網(wǎng)絡的TSF,更新校準本地的TSF。

注:協(xié)議規(guī)范【原文】

A non-DMG STA’s TSF timer shall be accurate to within ± 100 ppm. A DMG STA’s TSF timer shall be accurate to within ± 20 ppm.

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 路由器
    +關注

    關注

    22

    文章

    3738

    瀏覽量

    114127
  • SSID
    +關注

    關注

    0

    文章

    14

    瀏覽量

    11364
  • FCS
    FCS
    +關注

    關注

    4

    文章

    32

    瀏覽量

    14478
  • wifi網(wǎng)絡

    關注

    0

    文章

    12

    瀏覽量

    7431
收藏 人收藏

    評論

    相關推薦

    經(jīng)典藍牙解析說明

    在無線通信協(xié)議的開發(fā)過程中,器是工程師們不可或缺的工具。掌握器的使用,就如同擁有了能夠洞察無線電波的“火眼金睛”。這不僅使我們能夠驗證發(fā)出的數(shù)據(jù)
    的頭像 發(fā)表于 07-24 09:04 ?2099次閱讀
    經(jīng)典藍牙<b class='flag-5'>抓</b><b class='flag-5'>包</b>解析說明

    終端節(jié)點為什么無法?

    終端節(jié)點為什么無法?終端節(jié)點收不到協(xié)調器無線發(fā)送的數(shù)據(jù)包打斷點調試協(xié)調器無線發(fā)送成功,終端節(jié)點開啟低功耗模式,并且輪詢設置為5s,每5s向協(xié)調器發(fā)送data request請求。
    發(fā)表于 03-16 10:27

    WIZnet芯片通訊時怎么?

    `Q:WIZnet芯片進行公網(wǎng)通訊或者芯片間通訊的話怎么?A:芯片和PC通訊的話可以直接通過Wireshark,如果芯片和公網(wǎng)直接通訊或者通訊是發(fā)生在芯片之間,則沒有辦法直接
    發(fā)表于 03-13 11:32

    加密后分析的問題?

    請問一下,我的zigbee設備全部都開啟了加密, 使用軟件的時候,數(shù)據(jù)都是加密的,我應該怎么解密分析這些數(shù)據(jù)呢,謝謝了
    發(fā)表于 06-01 14:22

    若協(xié)調器斷電,然后重新上電,捕捉終端發(fā)出 orphan notification ,然后就開始發(fā)出 Beacon Request信號,怎么改一下能一直發(fā)orphan notification入網(wǎng)而不在發(fā)Beacon Request???

    [size=1em][size=1em]若[size=1em]協(xié)調器斷電,[size=1em]然后[size=1em]重新上電,[size=1em]捕捉終端發(fā)出 orphan
    發(fā)表于 06-01 10:50

    Packet Sniffer 異常,有時能抓到有時不到,有時協(xié)調器會回應有時不會回應,請問是怎么回事?

    有時不會回應。而且離線節(jié)點的beacon request 協(xié)調器雖然回應 但是節(jié)點沒有后續(xù)操作,都定義了NV_RESTORE附
    發(fā)表于 06-01 07:41

    BLE Execute Write Request Callback在哪里?請問我該如何知道合適數(shù)據(jù)已經(jīng)全部傳輸完畢?

    本帖最后由 一只耳朵怪 于 2018-6-7 09:37 編輯 BLE用WriteLongCharValue發(fā)送超過20個字節(jié)的,看到流程為:perpare write
    發(fā)表于 06-06 12:45

    請問ZigBee如何修改Data Request的發(fā)送次數(shù)?

    我給終端開啟了休眠,并關閉了終端一直發(fā)送Data Request。但是開啟了終端在喚醒之后發(fā)送傳感器數(shù)據(jù)之后收到數(shù)據(jù)確認幀之后發(fā)送Data Request,顯示只有一次Data
    發(fā)表于 08-09 09:18

    ZLL touchlink過程遇到問題的解決辦法?

    你好,對ZLLRC和Zlight2的touchlink過程進行,如附件,第1-16的數(shù)據(jù)還能理解,分別是掃描請求、掃描響應、識別、網(wǎng)絡
    發(fā)表于 08-07 10:45

    USB數(shù)據(jù)軟件程序下載

    USB數(shù)據(jù)軟件程序下載
    發(fā)表于 09-09 16:01 ?9次下載

    MCU_Wireshark USB 過濾(特定端口地址)

    啟動WiresharkUSB的過程如下,這里點擊“開始”就可以進入界面了。不過,Wireshark啟動USB
    發(fā)表于 12-08 16:36 ?14次下載
    MCU_Wireshark USB <b class='flag-5'>抓</b><b class='flag-5'>包</b>過濾(<b class='flag-5'>抓</b>特定端口地址)

    SRT協(xié)議的工作流程、數(shù)據(jù)結構及Wireshark分析

    摘 要:本文從SRT協(xié)議的工作流程談起,著重介紹和解析了SRT協(xié)議的數(shù)據(jù)結構,并舉例說明如何利用Wireshark軟件進行鏈路故障分析,從而解決實際工作中的問題。
    的頭像 發(fā)表于 05-17 10:08 ?3546次閱讀

    如何抓取app數(shù)據(jù) 網(wǎng)絡原理及實現(xiàn)

    要實現(xiàn)對App的網(wǎng)絡數(shù)據(jù),需要監(jiān)控App與服務器交互之間的網(wǎng)絡節(jié)點,監(jiān)控其中任意一個網(wǎng)絡節(jié)點(網(wǎng)卡),獲取所有經(jīng)過網(wǎng)卡中的數(shù)據(jù),對這些數(shù)據(jù)按照網(wǎng)絡協(xié)議進行解析,這就是
    發(fā)表于 08-11 09:30 ?3322次閱讀
    如何抓取app數(shù)據(jù)<b class='flag-5'>包</b> 網(wǎng)絡<b class='flag-5'>抓</b><b class='flag-5'>包</b>原理及實現(xiàn)

    如何利用eNSP進行實驗?

    使用Wireshark工具進行ping,并分析報文
    的頭像 發(fā)表于 09-12 09:32 ?4308次閱讀
    如何利用eNSP進行<b class='flag-5'>抓</b><b class='flag-5'>包</b>實驗?

    CentOS中使用tcpdump

    CentOS中使用tcpdump
    的頭像 發(fā)表于 10-28 14:48 ?291次閱讀