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

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

截獲BLE數(shù)據(jù)包看藍牙5協(xié)議流程

丫丫119 ? 來源:未知 ? 作者:肖冰 ? 2019-09-20 10:45 ? 次閱讀

使用的抓包工具:Ellisys

今天用的Ellisys的界面如下所示,可以分為三個部分, 左上為40個信道監(jiān)視圖,左下為某一個或者多個設(shè)備(MAC地址)的交互數(shù)據(jù),我們只談只談BLE,所以其他wifi,zigbee等功能可以忽略。

藍牙設(shè)備工作狀態(tài)介紹:

1.從機設(shè)備廣播狀態(tài):

Connectable LE Coded -> LE Coded

Connectable LE Coded -> 2M on aux

2.主機連接從機過程:

主機在2M PHY 下建立連接

2M PHY切換到1M PHY

3.藍牙MAC地址:

Slave: 0xF0F8F2D2BB7F

Master: F0:F8:F2:1F:57:1B

藍牙5 PHY層簡介:

藍牙連接

上一講講了藍牙5廣播數(shù)據(jù)分析,今天接著看連接過程,下圖是一個請求連接全過程,總共分為6個階段,1-4階段為廣播,5為請求連接,6為回應(yīng)連接。

1-4階段分析請參考上一篇文章:

5,6階段發(fā)生在數(shù)據(jù)信道上,5為連接請求,因為是專屬藍牙5連接,可以看到其指令為AUX_CONNECT_REQ(主請求),AUX_CONNECT_REQ攜帶的參數(shù)和BT4.2并無太大差異,hopping channel,interval,latency等等。

在接收到信號之后從機會回應(yīng)一幀AUX_CONNECT_REP。

PHY層更新

如上面所示,Sniffer是在2M PHY下建立的連接,整個抓包實驗,我把藍牙的PHY 從2M PHY更新到1M PHY,最后更新到Coded PHY,三個階段,如下圖所示。

2M -> 1M PHY更新和Coded PHY更新

從下圖可以看到,更新PHY階段有三個階段,主機發(fā)送更新請求:LLCP_PHY_REQUEST,在下圖右下可以看到,主機請求更新PHY 層到1M PHY, 從機接收到請求,并回復(fù)LLCP_PHY_RESPONSE,RSPONSE中回復(fù)主機可以用1M PHY,最后主機發(fā)送LLCP_PHY_UPDATE,進過幾個數(shù)據(jù)包的調(diào)整之后方能更新到1M PHY上。

1M PHY -> Coded PHY更新

過程和上面一致,不過多贅述。


總結(jié)

用兩張圖來總結(jié)我覺得恰到好處,圖1,藍牙5連接過程,圖2,藍牙5 PHY更新流程。

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

    關(guān)注

    114

    文章

    5866

    瀏覽量

    171029
  • 路由器
    +關(guān)注

    關(guān)注

    22

    文章

    3744

    瀏覽量

    114341
收藏 人收藏

    評論

    相關(guān)推薦

    I2C總線數(shù)據(jù)包結(jié)構(gòu)詳解

    。以下是I2C總線數(shù)據(jù)包結(jié)構(gòu)的詳解: 一、I2C總線數(shù)據(jù)包的基本組成 I2C總線上的數(shù)據(jù)傳輸以數(shù)據(jù)包為單位進行,每個數(shù)據(jù)包包含起始信號、設(shè)備
    的頭像 發(fā)表于 01-17 15:46 ?163次閱讀

    mtu配置步驟詳解 mtu與數(shù)據(jù)包丟失的關(guān)系

    MTU(Maximum Transmission Unit)即最大傳輸單元,是指一種通信協(xié)議的某一層上面所能通過的最大數(shù)據(jù)報大小,單位是字節(jié)。MTU配置步驟及其與數(shù)據(jù)包丟失的關(guān)系如下: MTU配置
    的頭像 發(fā)表于 12-16 14:33 ?1056次閱讀

    Linux網(wǎng)卡收流程

    Linux 網(wǎng)卡收流程如下 網(wǎng)卡收到數(shù)據(jù)包數(shù)據(jù)包從網(wǎng)卡硬件緩存移動到服務(wù)器內(nèi)存中(DMA方式,不經(jīng)過CPU) 通過硬中斷通知CPU處理 CPU通過軟中斷通知內(nèi)核處理 經(jīng)過TCP/
    的頭像 發(fā)表于 12-05 16:21 ?264次閱讀
    Linux網(wǎng)卡收<b class='flag-5'>包</b><b class='flag-5'>流程</b>

    請問DCTCP與DCUDP 的登錄數(shù)據(jù)包和心跳數(shù)據(jù)包與服務(wù)器端是如何交互的?

    DCTCP與DCUDP的登錄數(shù)據(jù)包和心跳數(shù)據(jù)包與服務(wù)器端是如何交互的?
    發(fā)表于 07-25 06:37

    使用AT SAVETRANSLINK時UDP數(shù)據(jù)包丟失怎么解決?

    Android 發(fā)送一個小 UDP 數(shù)據(jù)包5 字節(jié))。這個小數(shù)據(jù)包被我的微控制器在UART上接收到。微控制器將更大的數(shù)據(jù)包(可變長度,約 100 字節(jié))發(fā)送回 UART。ESP在U
    發(fā)表于 07-18 07:17

    帶你深入了解BLE藍牙模塊工作模式

    藍牙是一種新興無線通訊技術(shù)是一個標(biāo)準(zhǔn)的無線通訊協(xié)議,可實現(xiàn)無線數(shù)據(jù)和語音通信?;诘统杀驹O(shè)備的收發(fā)器芯片,可做近距離的無線連接,為固定和移動設(shè)備監(jiān)理通信環(huán)境的一種近距離無線連接技術(shù)。其中,BL
    的頭像 發(fā)表于 07-16 13:54 ?1056次閱讀
    帶你深入了解<b class='flag-5'>BLE</b><b class='flag-5'>藍牙</b>模塊工作模式

    能否在ESP結(jié)束之前通過串行端口停止傳入的UDP數(shù)據(jù)包的傳輸以解析下一個UDP數(shù)據(jù)包?

    我正在做一個artnet節(jié)點, 它收到幾個 UDP 廣播數(shù)據(jù)包,工作正常,但是: 其中一些必須使用,其中一些必須丟棄, mi問題是:所有傳入的數(shù)據(jù)包都出現(xiàn)在帶有IPD命令的串行端口上, 并且我需要
    發(fā)表于 07-16 06:18

    請問如何使用AT CIPSEND或AT CIPSENDBUF發(fā)送多個數(shù)據(jù)包?

    我可以使用 AT CIPSEND 發(fā)送單個數(shù)據(jù)包。但是我必須發(fā)送一系列二進制數(shù)據(jù)包。如何使用AT CISEND或AT CIPSENDBUF發(fā)送多個數(shù)據(jù)包,什么是正確的算法? 到目前為止,我嘗試
    發(fā)表于 07-15 07:37

    ESP32 BLE使用nimble協(xié)議棧怎樣才能發(fā)送超過20個字節(jié)的數(shù)據(jù)

    我在使用藍牙傳送傳感器數(shù)據(jù),目前只能發(fā)送20個字節(jié)大小的數(shù)據(jù)包,請問大家是如何實現(xiàn)發(fā)送大于20字節(jié)的數(shù)據(jù)包的。我想嘗試將數(shù)據(jù)包分包發(fā)送,但是
    發(fā)表于 06-17 07:18

    在AN65974中短數(shù)據(jù)包和零長數(shù)據(jù)包是什么意思?

    在 AN65974 中,短數(shù)據(jù)包和零長數(shù)據(jù)包是什么意思? 非常感謝!
    發(fā)表于 05-30 07:41

    如何在AIROC GUI上獲取良好數(shù)據(jù)包和總數(shù)據(jù)包

    使用 IQxel-MW LifePoint 作為發(fā)生器并發(fā)送波形BT_1DH5_00001111_Fs80M.iqvsg,但無法在 AIROC 工具中接收數(shù)據(jù)包。 以下是從 IQxel 發(fā)送
    發(fā)表于 05-22 06:39

    請問STM32WB55如何一次性發(fā)送和接收超過100字節(jié)的數(shù)據(jù)包?

    大家好,我使用的開發(fā)板是“STM32WB55 Nucleo”開發(fā)板,想實現(xiàn)一次性發(fā)送和接收超過100個字節(jié)的數(shù)據(jù)包數(shù)據(jù)包字節(jié)數(shù)越多越好,如果能達到250個字節(jié)就最好了)。藍牙底層數(shù)據(jù)包
    發(fā)表于 04-12 07:03

    請問高端網(wǎng)絡(luò)芯片如何處理數(shù)據(jù)包呢?

    隨著網(wǎng)絡(luò)芯片帶寬的持續(xù)提升,其內(nèi)部數(shù)據(jù)包處理單元的工作負載也隨之增加。然而,如果處理單元無法與網(wǎng)絡(luò)接口的傳入速率相匹配,將無法及時處理數(shù)據(jù)包,這不僅會導(dǎo)致數(shù)據(jù)包隨機丟失,更會降低網(wǎng)絡(luò)的吞吐量。
    的頭像 發(fā)表于 04-02 16:36 ?687次閱讀
    請問高端網(wǎng)絡(luò)芯片如何處理<b class='flag-5'>數(shù)據(jù)包</b>呢?

    STM32H7接收數(shù)據(jù)包異常,一接收的數(shù)據(jù)出現(xiàn)兩發(fā)送的內(nèi)容怎么解決?

    );__HAL_UART_DISABLE_IT( huart1, DMA_IT_HT); 2、發(fā)送數(shù)據(jù)包1
    發(fā)表于 03-08 08:05

    DPDK在AI驅(qū)動的高效數(shù)據(jù)包處理應(yīng)用

    傳統(tǒng)的數(shù)據(jù)包處理方式是數(shù)據(jù)包先到內(nèi)核最后再到用戶層進行處理。這種方式會增加額外的延遲和CPU開銷,嚴(yán)重影響數(shù)據(jù)包處理的性能。 DPDK 繞過內(nèi)核,在用戶空間中實現(xiàn)快速數(shù)據(jù)包處理。
    的頭像 發(fā)表于 02-25 11:28 ?1016次閱讀
    DPDK在AI驅(qū)動的高效<b class='flag-5'>數(shù)據(jù)包</b>處理應(yīng)用