| btmon(1) | مدیریت سیستم لینوکس | btmon(1) |
نام (NAME)
btmon - مانیتورینگ و رهگیری ترافیک و بستههای پروتکلهای بلوتوث HCI
خلاصه دستور (SYNOPSIS)
btmon [OPTIONS ...]
توضیحات (DESCRIPTION)
دستور btmon(1) دسترسی به زیرساخت مانیتورینگ زیرسیستم بلوتوث را برای خواندن رهگیریهای (traces) پروتکل HCI فراهم میکند.
گزینهها (OPTIONS)
- -r FILE, --read FILE
- خواندن ردگیریها (traces) با قالب btsnoop از FILE.
- -w FILE, --write FILE
- ذخیره ردگیریها با قالب btsnoop در FILE.
- -a FILE, --analyze FILE
- تحلیل ردگیریها با قالب btsnoop از FILE. این گزینه دستگاههای یافتشده در FILE را به همراه بستههای آنها بر اساس نوع نمایش میدهد. اگر gnuplot روی سیستم نصب باشد، برای رسم نمودار تاخیر زمانی بستهها نیز تلاش میکند.
- -s SOCKET, --server SOCKET
- راهاندازی سوکت سرور مانیتور.
- -p PRIORITY, --priority PRIORITY
- نمایش لاگهای کاربر تنها با اولویت مشخصشده یا پایینتر.
| اولویت (PRIORITY) | نام (NAME) |
| 3 | خطا (Error) |
| 4 | هشدار (Warning) |
| 6 | اطلاعات (پیشفرض) |
| 7 | اشکالزدایی (Debug). میتوان از debug نیز استفاده کرد. |
- -i NUM, --index NUM
- تنها کنترلکننده مشخصشده را نمایش میدهد. hciNUM نیز قابل قبول است. این گزینه برای ثبت و رهگیری ترافیک از یک کنترلکننده خاص در هنگام وجود چندین کنترلکننده کاربرد دارد.
- -d TTY, --tty TTY
- خواندن دادهها از TTY.
- -B SPEED, --rate SPEED
- تنظیم سرعت TTY. مقدار پیشفرض SPEED برابر 115300 است.
- -V COMPID, --vendor COMPID
- تنظیم
شناسه
پیشفرض
شرکت
سازنده. COMPID
یک شماره
یکتا است که
توسط Bluetooth SIG به
شرکتهای
عضو اختصاص
داده
میشود و در
وبسایت Bluetooth SIG
قابل جستجو
و مشاهده
است.
برای نمونه، شناسه اینتل (Intel) برابر 2 و ریالتک (Realtek) برابر 93 است.
- -M, --mgmt
- باز کردن کانال برای رویدادهای مدیریتی (mgmt).
- -K, --kernel
- باز کردن kmsg برای پیامهای هسته (kernel).
- -t, --time
- نمایش زمان به جای افست زمانی (فاصله زمانی از شروع).
- -T, --date
- نمایش اطلاعات تاریخ و زمان به جای افست زمانی.
- -N, --no-time
- عدم نمایش کامل برچسب و افست زمانی.
- -S, --sco
- تخلیه (Dump) ترافیک صوتی SCO با قالب هگزادسیمال خام.
- -A, --a2dp
- تخلیه ترافیک استریم A2DP با قالب هگزادسیمال خام.
- -I, --iso
- تخلیه ترافیک استریم همگام (ISO) با قالب هگزادسیمال خام. برای مشاهده دادههای همگام LE Audio در خروجی مورد نیاز است.
- -E IP, --ellisys IP
- ارسال تزریق HCI الیسیس (Ellisys HCI Injection).
- -P, --no-pager
- غیرفعال کردن استفاده از پیجر (مانند less) هنگام خواندن فایل لاگ.
- -J OPTIONS, --jlink OPTIONS
- خواندن دادهها از RTT. هر گزینه بدون فاصله و با کاما (,) جدا میشود.
| گزینهها (OPTIONS) | توضیحات (Description) |
| DEVICE | اجباری. تنظیم دستگاه هدف. |
| SERIALNO | (اختیاری) تنظیم شماره سریال USB. پیشفرض 0 است. |
| INTERFACE | (اختیاری) رابط هدف. پیشفرض swd است. |
| SPEED | (اختیاری) تنظیم سرعت رابط هدف بر حسب کیلوهرتز (kHz). پیشفرض 1000 است. |
- -R OPTIONS, --rtt OPTIONS
- پارامترهای بلوک کنترل RTT. هر گزینه بدون فاصله و با کاما (,) جدا میشود.
| گزینهها (OPTIONS) | توضیحات (Description) |
| ADDRESS | (اختیاری) آدرس بافر RTT. پیشفرض 0x00 است. |
| AREA | (اختیاری) اندازه محدوده برای جستجو در بافر RTT. پیشفرض 0 است. |
| NAME | (اختیاری) نام بافر. پیشفرض btmonitor است. |
- -C WIDTH, --columns WIDTH
- عرض خروجی در صورتی که خروجی یک ترمینال نباشد.
- -c MODE, --color MODE
- تنظیم رنگ
خروجی.
مقادیر
ممکن برای
MODE عبارتند
از: auto|always|never.
مقدار پیشفرض auto است.
- -v, --version
- نمایش نسخه
- -h, --help
- نمایش گزینههای راهنما
خواندن خروجی (READING THE OUTPUT)
خروجی btmon به صورت جریانی از فریمها سازماندهی شده است که هر کدام نشاندهنده یک رویداد منفرد در زیرسیستم بلوتوث هستند. درک قالب خروجی برای عیبیابی و اشکالزدایی مشکلات بلوتوث ضروری است.
پیشوندهای خطوط (Line Prefixes)
هر فریم با یک پیشوند تکنویسهای شروع میشود که منبع و نوع آن را مشخص میکند:
| پیشوند (Prefix) | مفهوم (Meaning) | توضیحات (Description) |
| < | ارسال دستور / داده HCI (HCI Command / Data TX) | ارسالشده از میزبان به کنترلکننده (خروجی). دستورات HCI، دادههای ACL/SCO/ISO ارسالشده به کنترلکننده. |
| > | دریافت رویداد / داده HCI (HCI Event / Data RX) | دریافتشده از کنترلکننده به میزبان (ورودی). رویدادهای HCI، دادههای ACL/SCO/ISO دریافتشده از کنترلکننده. |
| @ | ترافیک مدیریتی (Management traffic) | دستورات و رویدادهای رابط مدیریتی (MGMT) بین bluetoothd و لایه مدیریتی هسته (kernel). |
| = | یادداشتهای سیستمی (System notes) | توضیحات و یادداشتهای سطح سیستم: اطلاعات هسته، تغییرات ایندکس، پیامهای لاگ فرایندها، و سیگنالهای D-Bus. |
ترافیک HCI (HCI Traffic) (< و >)
فریمهای HCI نشاندهنده ارتباط واقعی بین نرمافزار میزبان و سختافزار کنترلکننده بلوتوث هستند.
کالبدشکافی یک خط دستور HCI:
< HCI Command: Reset (0x03|0x0003) plen 0 #5 [hci0] 12:35:01.843185 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └─ Timestamp │ │ │ │ │ │ └─ Controller │ │ │ │ │ └─ Frame number │ │ │ │ └─ Parameter length (bytes) │ │ │ └─ Full opcode (16-bit) │ │ └─ OGF|OCF (Opcode Group / Command Field) │ └─ Command name (human-readable) └─ Direction: < = Host to Controller (outgoing)
کالبدشکافی یک خط رویداد HCI:
> HCI Event: Command Complete (0x0e) plen 4 #6 [hci0] 12:35:01.864922 │ │ │ │ │ │ │ │ │ │ │ └─ Timestamp │ │ │ │ └─ Controller │ │ │ └─ Frame number │ │ └─ Parameter length │ └─ Event code │ └─ Direction: > = Controller to Host (incoming)
جهت < به این معنی است که میزبان در حال ارسال به کنترلکننده است (دستورات و دادهها). جهت > به این معنی است که کنترلکننده در حال ارسال به میزبان است (رویدادها و دادهها). از دیدگاه کنترلکننده به این موضوع نگاه کنید: < ورودی به کنترلکننده است و > خروجی صادر شده از آن است.
دستورات HCI با پارامتر با خطوط جزئیات دارای تورفتگی همراه هستند:
< HCI Command: LE Set Extende.. (0x08|0x0039) plen 2 #1 [hci0] 12:35:01.738352
Extended advertising: Disabled (0x00)
Number of sets: Disable all sets (0x00)
پاسخهای رویداد HCI به دستوری که تکمیل میکنند ارجاع میدهند:
> HCI Event: Command Complete (0x0e) plen 4 #6 [hci0] 12:35:01.864922
Reset (0x03|0x0003) ncmd 2
Status: Success (0x00)
در اینجا ncmd 2 نشان میدهد که کنترلکننده میتواند ۲ دستور دیگر را بپذیرد (کنترل جریان HCI یا flow control). بدنه دارای تورفتگی دستوری را که این رویداد تکمیل میکند و وضعیت نتیجه را نشان میدهد.
فرا رویدادهای LE (LE Meta Events) شامل یک نوع زیررویداد (subevent) هستند:
> HCI Event: LE Meta Event (0x3e) plen 31 #487 [hci0] 12:36:18.974201
LE Enhanced Connection Complete (0x0a)
Status: Success (0x00)
Handle: 2048
Role: Peripheral (0x01)
Peer address type: Public (0x00)
Peer address: AA:BB:CC:DD:EE:FF (OUI Company)
Connection interval: 60.00 msec (0x0030)
Connection latency: 0 (0x0000)
Supervision timeout: 9600 msec (0x03c0)
دادههای ACL ترافیک صفحه داده (data plane) را همراه با هندل (handle) و رمزگشایی پروتکل نشان میدهد:
< LE-ACL: Handle 2048 [66:B0:26:F1:D3:BC] [1/6] flags 0x00 dlen 16 #493 [hci0] 12:36:18.977915 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └─ Timestamp │ │ │ │ │ │ │ │ └─ Controller │ │ │ │ │ │ │ └─ Frame number │ │ │ │ │ │ └─ Data length │ │ │ │ │ └─ flags │ │ │ │ └─ Buffer tracking (optional) │ │ │ └─ Peer address (optional) │ │ └─ Handle number │ └─ Connection-type-aware label (e.g. BR-ACL, LE-ACL, BR-SCO, LE-ISO) └─ Direction marker: '<' = host->controller (TX), '>' = controller->host (RX)
دادههای ACL به طور خودکار به پروتکلهای لایههای بالاتر رمزگشایی میشوند:
< LE-ACL: Handle 2048 [2/6] flags 0x00 dlen 7 #494 [hci0] 12:36:18.978488
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
> LE-ACL: Handle 2048 flags 0x02 dlen 11 #497 [hci0] 12:36:19.000048
SMP: Pairing Request (0x01) len 6
IO capability: NoInputNoOutput (0x03)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, SC, No Keypresses, CT2 (0x2d)
Max encryption key size: 16
ترافیک مدیریتی (Management Traffic) (@)
خطوطی که با @ شروع میشوند ترافیک رابط مدیریتی را نشان میدهند -- پروتکل ساختاریافته دستور/رویداد بین bluetoothd و لایه مدیریتی هسته (نگاه کنید به doc/mgmt-protocol.rst).
کالبدشکافی یک خط مدیریتی:
@ MGMT Command: Set Powered (0x0005) plen 1 {0x0001} [hci0] 12:35:04.033564
│ │ │ │ │ │
│ │ │ │ │ └─ Timestamp
│ │ │ │ └─ Controller
│ │ │ └─ MGMT socket ID
│ │ └─ Parameter length
│ └─ MGMT opcode
└─ @ = Management channel
عبارت {0x0001} شناسه سوکت مدیریتی است -- که تمایز بین چندین کلاینت مدیریتی (به عنوان مثال اجرای همزمان bluetoothd و btmgmt) را مشخص میکند.
MGMT Open/Close زمان اتصال فرایندها به کانال مدیریتی را رهگیری میکند:
@ MGMT Open: bluetoothd (privileged) version 1.23 {0x0001} 12:34:49.881936
@ MGMT Close: bluetoothd {0x0001} 12:35:01.866256
این موارد نام فرایند، سطح دسترسی (امتیاز) و نسخه پروتکل را نمایش میدهند.
دستورات MGMT به همراه پارامترها:
@ MGMT Command: Set Powered (0x0005) plen 1 {0x0001} [hci0] 12:35:04.033564
Powered: Enabled (0x01)
رویدادهای MGMT (پاسخها و اعلانها):
@ MGMT Event: Command Complete (0x0001) plen 7 {0x0001} [hci0] 12:35:04.114789
Set Powered (0x0005) plen 4
Status: Success (0x00)
Current settings: 0x004e0ac1
Powered
Secure Simple Pairing
MGMT بدون ایندکس کنترلکننده (عملیاتهای سراسری):
@ MGMT Command: Read Management Ver.. (0x0001) plen 0 {0x0001} 12:35:04.027771
@ MGMT Event: Command Complete (0x0001) plen 6 {0x0001} 12:35:04.027776
توجه داشته باشید که عبارتی نظیر [hci0] وجود ندارد -- این دستورات در سطح سیستم عمل میکنند، نه بر روی یک کنترلکننده خاص.
یادداشتهای سیستمی (System Notes) (=)
خطوطی که با = شروع میشوند یادداشتها و حاشیهنویسیهای سطح سیستم هستند که توسط هسته یا توسط فرایندها از طریق کانال مانیتور تزریق میشوند. این خطوط ترافیک پروتکل HCI یا MGMT نیستند.
اطلاعات هسته (Kernel information) (در هنگام راهاندازی نمایش داده میشود):
= Note: Linux version 6.16.0-rc6-0903 (x86_64) 12:34:49.881926 = Note: Bluetooth subsystem version 2.22 12:34:49.881930
چرخه حیات ایندکس (Index lifecycle) (افزودن/حذف/باز شدن/بسته شدن کنترلکننده):
= New Index: 00:11:22:33:44:55 (Primary,USB,hci0) [hci0] 12:34:49.881932 = Open Index: 00:11:22:33:44:55 [hci0] 12:34:49.881933 = Index Info: 00:11:22:33:44:55 (OUI Company) [hci0] 12:34:49.881934 = Close Index: 00:11:22:33:44:55 [hci0] 12:35:01.865125
- New Index -- یک کنترلکننده در هسته ثبت شد
- Open Index -- یک کنترلکننده فعال شد
- Index Info -- اطلاعات شرکت سازنده کنترلکننده
- Close Index -- یک کنترلکننده غیرفعال شد
پیامهای لاگ فرایندها (Process log messages) (خروجی اشکالزدایی از bluetoothd و سایر دیمنها):
= bluetoothd: src/adapter.c:connected_callback() hci0 devic.. 12:36:18.975307 │ │ │ │ │ └─ Timestamp │ └─ Source file, function, and message (may be truncated) └─ Process name
این خطوط هنگامی که bluetoothd با اشکالزدایی فعال (-d) اجرا شود یا هنگامی که فرایندی در کانال لاگگیری هسته بنویسد، ظاهر میشوند. آنها مسیر فایل منبع، نام تابع و پیام لاگ را نشان میدهند -- که برای پیوند دادن تصمیمات داخلی دیمن با ترافیک HCI پیرامون آن بسیار ارزشمند است.
فعالیت D-Bus (D-Bus activity) (سیگنالها و فراخوانیهای متد):
= bluetoothd: [:1.21220:method_call] > org.freedesktop.DBus.. 12:34:53.912508 = bluetoothd: [:1.21220:method_return] < [#5] 12:34:53.912546 = bluetoothd: [signal] org.freedesktop.DBus.ObjectManager.I.. 12:36:18.975691
قالب آن [bus_name:message_type] است که به دنبال آن > (خروجی) یا < (ورودی) میآید. توجه داشته باشید که علائم > و < در یادداشتهای سیستمی D-Bus نشاندهنده جهت پیام D-Bus هستند، نه جهت HCI.
متادادههای سمت راست (Right-Side Metadata)
هر خط دارای متادادههایی است که در انتهای آن راستچین شدهاند. فیلدهای دقیق به نوع خط بستگی دارند:
┌─ Main content (left-aligned, variable width)
│ ┌─ Frame # ─┐ ┌Controller┐ ┌─ Timestamp ─┐
│ │ │ │ │ │ │
< HCI Command: Reset (0x03|0x0003) plen 0 #5 [hci0] 12:35:01.843185
> HCI Event: Command Complete (0x0e) plen 4 #6 [hci0] 12:35:01.864922
@ MGMT Command: Set Powered (0x0005) plen 1 {0x0001} [hci0] 12:35:04.033564
= Note: Linux version 6.16.0-rc6-0903 (x86_64) 12:34:49.881926
= Open Index: 00:11:22:33:44:55 [hci0] 12:34:49.881933
شماره فریم (Frame number) (#N): یک شمارنده ترتیبی فقط برای فریمهای HCI. برای شناسایی بستههای خاص در یک رهگیری کاربرد دارد. فقط ترافیک HCI (< و >) شماره فریم دریافت میکند -- MGMT (@) و یادداشتهای سیستمی (=) شماره فریم ندارند.
کنترلکننده (Controller) ([hciN]): مشخص میکند که فریم متعلق به کدام کنترلکننده بلوتوث است. برای عملیاتهای سراسری (یادداشتهای هسته، دستورات MGMT بدون ایندکس کنترلکننده) وجود ندارد.
شناسه سوکت MGMT (MGMT socket ID) ({0xNNNN}): در خطوط @ به جای شماره فریم نمایش داده میشود. مشخص میکند کدام سوکت مدیریتی (فرایند) دستور را ارسال کرده است.
برچسب زمانی (Timestamp): همیشه راستترین فیلد است. قالب آن به گزینه استفادهشده در خط فرمان بستگی دارد:
| گزینه (Option) | قالب (Format) | مثال (Example) |
| (پیشفرض) | ثانیه از زمان شروع رهگیری | 0.881932 |
| -t | زمان روز (HH:MM:SS.usec) | 12:35:01.843185 |
| -T | تاریخ و زمان کامل | 2026-01-13 12:34:49.881926 |
خطوط جزئیات دارای تورفتگی (Indented Detail Lines)
خطوطی که زیر سرایند فریم دارای تورفتگی هستند، حاوی بار داده (payload) رمزگشاییشده آن فریم میباشند. سطح تورفتگی لایه پروتکل را مشخص میکند:
- سطح اول (۶ فاصله): بار داده مستقیم فریم HCI/MGMT
- سطح دوم (۸ فاصله): فیلدهای رمزگشاییشده درون بار داده
- سطح سوم (۱۰+ فاصله): دادههای پروتکل تودرتو (به عنوان مثال L2CAP درون ACL، یا ATT درون L2CAP)
مثالی از لایهبندی پروتکل در دادههای ACL:
> ACL: Handle 2048 flags 0x02 dlen 11 #497 [hci0] 12:36:19.000048
SMP: Pairing Request (0x01) len 6 ← L2CAP/SMP layer
IO capability: NoInputNoOutput (0x03) ← SMP fields
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, SC (0x2d)
Max encryption key size: 16
نکات برچسب زمانی (Timestamp Notes)
هنگام خواندن فایلهای btsnoop با -t یا -T، برچسبهای زمانی نشاندهنده زمان واقعی (wall-clock time) ثبتشده در فایل btsnoop هستند. دقت به منبع بستگی دارد:
- رهگیری زنده (Live capture) (کانال مانیتور btmon): دقت میکروثانیه از هسته.
- فایلهای btsnoop: قالب btsnoop برچسبهای زمانی را به صورت میکروثانیه از مبدا تاریخ (epoch) ذخیره میکند، بنابراین دقت کامل میکروثانیه حفظ میشود. صفرهای انتهایی در نمایش (مانند 14:38:46.589000) نشان میدهند که منبع اصلی رهگیری دارای دقت میلیثانیه بوده است.
حالت پیشفرض برچسب زمانی، ثانیههای سپریشده از اولین بسته در ردگیری را نشان میدهد که برای اندازهگیری فواصل زمانی بین رویدادها بدون نیاز به دانستن زمان مطلق کاربرد دارد.
شماره فریم در مقایسه با شماره خط (Frame Numbers vs Line Numbers)
نرمافزار btmon شمارههای فریم ترتیبی (#N) را به بستههای HCI اختصاص میدهد. اینها شناسههای پایداری برای بستههای خاص صرفنظر از قالببندی خروجی هستند. با این حال، هنگام پردازش خروجی متنی btmon با ابزارهایی مانند grep یا sed، واحد مورد نظر شماره خطوط در فایل خروجی است. این دو ارتباطی به هم ندارند:
- یک فریم منفرد ممکن است چندین خط خروجی تولید کند (سرایند + فیلدهای رمزگشاییشده).
- شمارههای فریم فقط برای ترافیک HCI (< و >) اعمال میشوند. ترافیک MGMT (@) و یادداشتهای سیستمی (=) شماره فریم ندارند.
- هنگام ارجاع به بستههای خاص، شماره فریمها (#487) را به شماره خطوط ترجیح دهید، زیرا شمارههای فریم در عرضهای مختلف ترمینال و گزینههای قالببندی گوناگون پایدار و بدون تغییر باقی میمانند.
راهنمای عملی خواندن خروجی (Practical Reading Guide)
جفت معمول دستور-پاسخ:
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0 #13 [hci0] 12:35:04.057866
> HCI Event: Command Complete (0x0e) plen 10 #14 [hci0] 12:35:04.058750
Read BD ADDR (0x04|0x0009) ncmd 1
Status: Success (0x00)
Address: 00:11:22:33:44:55 (OUI Company)
این مورد را به این صورت بخوانید: در فریم #13، میزبان از کنترلکننده آدرس بلوتوث آن را درخواست کرد. در فریم #14، کنترلکننده با موفقیت و آدرس 00:11:22:33:44:55 پاسخ داد. این پاسخ حدود 0.9 میلیثانیه بعد دریافت شد.
جریان معمول MGMT که ارتباط با HCI را نشان میدهد:
@ MGMT Command: Set Powered (0x0005) plen 1 {0x0001} [hci0] 12:35:04.033564
Powered: Enabled (0x01)
< HCI Command: Reset (0x03|0x0003) plen 0 #7 [hci0] 12:35:04.033907
> HCI Event: Command Complete (0x0e) plen 4 #8 [hci0] 12:35:04.055753
Reset (0x03|0x0003) ncmd 2
Status: Success (0x00)
... (more HCI commands to configure the controller) ...
@ MGMT Event: Command Complete (0x0001) plen 7 {0x0001} [hci0] 12:35:04.114789
Set Powered (0x0005) plen 4
Status: Success (0x00)
این مورد را به این صورت بخوانید: سرویس bluetoothd دستور Set Powered را از طریق MGMT ارسال کرد. هسته این دستور را به دنبالهای از دستورات HCI (ابتدا Reset، سپس پیکربندی) ترجمه کرد. پس از تکمیل تمام دستورات HCI، هسته رویداد MGMT Command Complete را به bluetoothd برگرداند.
جریان برقراری اتصال:
> HCI Event: LE Meta Event (0x3e) plen 31 #487 [hci0] 12:36:18.974201
LE Enhanced Connection Complete (0x0a)
Status: Success (0x00)
Handle: 2048
Role: Peripheral (0x01)
Peer address: AA:BB:CC:DD:EE:FF (OUI Company)
@ MGMT Event: Device Connec.. (0x000b) plen 13 {0x0001} [hci0] 12:36:18.974319
= bluetoothd: src/adapter.c:connected_callback() hci0 devic.. 12:36:18.975307
< ACL: Handle 2048 [1.. flags 0x00 dlen 16 #493 [hci0] 12:36:18.977915
LE L2CAP: Connection Parameter Update Request (0x12) ident 1 len 8
< ACL: Handle 2048 [2/6] flags 0x00 dlen 7 #494 [hci0] 12:36:18.978488
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
این مورد را به این صورت بخوانید: کنترلکننده یک اتصال جدید LE را گزارش کرد (رویداد HCI). هسته این رویداد را به عنوان رویداد MGMT Device Connected به لایههای بالاتر هدایت کرد. سپس bluetoothd تابع connected_callback() خود را لاگ کرد. پس از آن تبادل داده آغاز شد -- یک بهروزرسانی پارامتر L2CAP و مذاکره ATT MTU از طریق اتصال جدید ACL.
حالت تحلیل (ANALYZE MODE)
گزینه -a (--analyze) یک فایل btsnoop را خوانده و به جای ردگیری کامل رمزگشاییشده، یک خلاصه آماری تولید میکند.
نحوه استفاده (Usage)
$ btmon -a hcidump.log
محتویات خروجی (Output Contents)
حالت تحلیل، برای هر کنترلکننده یافتشده در رهگیری، موارد زیر را گزارش میکند:
- تعداد بستهها (Packet counts): کل بستههای HCI تفکیکشده بر اساس نوع (دستورات، رویدادها، ACL، SCO، ISO، تشخیص عیب شرکت سازنده، یادداشتهای سیستمی، لاگهای کاربر، پیامهای کنترلی).
- آمار به ازای هر اتصال (Per-connection statistics): برای هر هندل اتصال یافتشده:
- نوع اتصال (BR-ACL, LE-ACL, BR-SCO, BR-ESCO, LE-ISO)
- آدرس دستگاه
- تعداد بستههای TX و RX و تعداد تکمیلها
- آمار تاخیر زمانی (حداقل، حداکثر، میانه) به میلیثانیه
- آمار اندازه بسته (حداقل، حداکثر، میانگین) به بایت (اکتت)
- تخمین پهنای باند (Throughput) بر حسب کیلوبیت بر ثانیه (Kb/s)
- آمار به ازای هر کانال (Per-channel statistics): برای هر کانال L2CAP در یک اتصال، همان آمارهای بسته/تاخیر زمانی/اندازه.
- نمودارهای تاخیر زمانی (Latency plots): اگر gnuplot نصب باشد، نمودارهای توزیع تاخیر زمانی با هنر اسکی (ASCII-art) در ترمینال رسم میشوند.
کدهای خطای پروتکل (PROTOCOL ERROR CODES)
برنامه btmon کدهای خطا را از چندین لایه پروتکل بهطور خودکار رمزگشایی میکند. این بخش یک مرجع راهنما برای تفسیر خطاهای دیدهشده در لایههای ATT ،SMP و L2CAP ارائه میدهد.
کدهای خطای ATT (ATT Error Codes)
خطاهای ATT در PDUهای Error Response (0x01) ظاهر میشوند. فراتر از زمینه کشف GATT (جایی که Attribute Not Found امری عادی است)، این خطاها نشاندهنده مشکلات واقعی هستند:
| کد | خطا | مفهوم تشخیصی |
| 0x01 | Invalid Handle | کلاینت از یک دستگیره (handle) استفاده کرده که وجود ندارد |
| 0x02 | Read Not Permitted | مشخصه (Characteristic) اجازه خواندن را نمیدهد |
| 0x03 | Write Not Permitted | مشخصه اجازه نوشتن را نمیدهد |
| 0x05 | Authentication Insufficient | عملیات نیازمند یک پیوند (bond) احراز هویتشده (محافظتشده در برابر MITM) است. در صورت عدم پیوند قبلی، جفتسازی SMP را فعال میکند. |
| 0x06 | Request Not Supported | سرور از این عملیات ATT پشتیبانی نمیکند |
| 0x07 | Invalid Offset | آفست خواندن/نوشتن دادههای حجیم (blob) از طول صفت (attribute) فراتر میرود |
| 0x08 | Authorization Insufficient | سرور نیازمند مجوز دسترسی (authorization) اضافی است |
| 0x09 | Prepare Queue Full | تعداد بیش از حدی از نوشتنهای آمادهشده در صف قرار گرفته است |
| 0x0a | Attribute Not Found | هیچ صفتی در محدوده درخواستی یافت نشد. پایان عادی برای روندهای کشف GATT. |
| 0x0b | Attribute Not Long | صفت نمیتواند با Read Blob خوانده شود |
| 0x0c | Insufficient Encryption Key Size | کلید رمزنگاری بیش از حد کوتاه است |
| 0x0d | Invalid Attribute Value Length | طول مقدار نوشتهشده برای این صفت نادرست است |
| 0x0e | Unlikely Error | خطای بعید عمومی (Generic unlikely error) |
| 0x0f | Insufficient Encryption | پیوند رمزنگاری نشده است. راهاندازی رمزنگاری را فعال میکند. |
| 0x10 | Unsupported Group Type | نوع صفت، یک نوع گروهبندی معتبر نیست |
| 0x11 | Insufficient Resources | سرور دچار کمبود منابع شده است |
| 0x12 | Value Not Allowed | مقدار در محدوده مجاز قرار ندارد |
| 0x80-0x9f | Application Error | خطای مختص برنامه کاربردی؛ معنای آن به پروفایل/سرویس بستگی دارد. پروتکل ASCS از این خطاها برای خطاهای خاص ASE استفاده میکند. |
| 0xfc | Write Request Rejected | درخواست نوشتن رد شد (CSIP, ASCS) |
| 0xfd | CCC Descriptor Improperly Configured | توصیفگر CCC باید پیش از برخی عملیات خاص فعال شود |
| 0xfe | Procedure Already in Progress | روند دیگری در حال حاضر در حال اجرا است |
| 0xff | Out of Range | مقدار خارج از محدوده معتبر است |
نتایج پاسخ اتصال L2CAP (L2CAP Connection Response Results)
پاسخ اتصال L2CAP و پاسخ اتصال LE شامل یک کد نتیجه هستند:
| کد | نتیجه | مفهوم تشخیصی |
| 0x0000 | Connection successful | کانال بهطور عادی برقرار شد |
| 0x0001 | Connection pending | اتصال در حال انجام است (فقط BR/EDR) |
| 0x0002 | Connection refused - PSM not supported | دستگاه راه دور سروری برای این پروتکل ندارد |
| 0x0003 | Connection refused - security block | الزامات امنیتی برآورده نشدهاند |
| 0x0004 | Connection refused - no resources | منابع کانال دستگاه راه دور به پایان رسیده است |
| 0x0005 | Connection refused - invalid Source CID | شناسه CID مبدأ نامعتبر است یا در حال حاضر استفاده میشود |
| 0x0006 | Connection refused - Source CID already allocated | تداخل CID (برخورد شناسه کانال) |
| 0x0007 | Connection refused - unacceptable parameters | مبتنی بر اعتبار LE: پارامترهای MTU ،MPS یا اعتبارات غیرقابل قبول هستند |
| 0x0008 | Connection refused - invalid parameters | مقادیر پارامترها نامعتبر هستند |
| 0x0009 | Connection refused - insufficient authentication | احراز هویت انجام نشده است |
| 0x000a | Connection refused - insufficient authorization | مجوز دسترسی صادر نشده است |
| 0x000b | Connection refused - insufficient encryption key size | کلید رمزنگاری بیش از حد کوتاه است |
| 0x000c | Connection refused - insufficient encryption | پیوند رمزنگاری نشده است |
خودکارسازی تشخیص خطا (Automating Error Detection)
یافتن تمام خطاهای ATT (به استثنای خاتمه عادی فرایند کشف):
grep -n "Error Response" output.txt
سپس بررسی کنید که آیا هر خطا مربوط به Attribute Not Found (0x0a) درون یک دنباله کشف است (عادی) یا یک کد خطای متفاوت (مشکل).
یافتن تمام خطاهای مرتبط با احراز هویت/رمزنگاری:
grep -n "Authentication Insufficient\|Insufficient Encryption\|Insufficient Security\|security block" output.txt
این خطاها نشان میدهند که پیوند نیازمند جفتسازی یا رمزنگاری است. بررسی کنید که آیا جفتسازی SMP در ادامه رخ میدهد یا خیر.
یافتن تمام موارد رد کانال L2CAP:
grep -n "Connection refused" output.txt
همبستگی خطاهای میانلایهای (Cross-layer error correlation):
خطاها اغلب به صورت آبشاری در میان لایهها منتقل میشوند. الگوهای متداول:
- 1.
- خطای ATT Insufficient Encryption (0x0f) → راهاندازی HCI LE Start Encryption → موفقیت Encryption Change → تلاش مجدد برای عملیات ATT
- 2.
- خطای ATT Authentication Insufficient (0x05) → راهاندازی SMP Pairing Request → تکمیل جفتسازی → تلاش مجدد برای عملیات ATT
- 3.
- رویداد SMP Pairing Failed → رویداد Disconnect Complete با دلیل Authentication Failure (0x05)
- 4.
- پیام L2CAP Connection refused - security block → راهاندازی جفتسازی SMP
جریانهای پروتکل (PROTOCOL FLOWS)
دنباله راهاندازی اولیه HCI (HCI INITIALIZATION SEQUENCE)
هر رهگیری btsnoop که راهاندازی کنترلکننده را ثبت میکند، با یک بلوک فشرده از دستورات و رویدادهای HCI آغاز میشود. این زیرسیستم بلوتوث هسته است که کنترلکننده را از طریق یک دنباله چندمرحلهای تعریفشده در net/bluetooth/hci_sync.c راهاندازی اولیه میکند. درک این دنباله کمک میکند تا ترافیک عادی راهاندازی اولیه را از مشکلات سطح برنامه تفکیک کنید.
نمای کلی (Overview)
هسته، یک کنترلکننده بلوتوث را پس از باز کردن دستگاه HCI در چهار مرحله راهاندازی اولیه میکند. هر مرحله دستهای از دستورات HCI را ارسال کرده و پیش از رفتن به مرحله بعد، منتظر تکمیل آنها میماند. زنجیره فراخوانی کامل به صورت زیر است:
hci_power_on_sync
└─ hci_dev_open_sync
└─ hci_dev_init_sync
├─ hci_dev_setup_sync (driver setup + quirks)
└─ hci_init_sync
├─ Stage 1: Reset + identity
├─ Stage 2: Capabilities + buffer sizes
├─ Stage 3: Event masks + policy
└─ Stage 4: Final configuration
پس از تکمیل هر چهار مرحله، یک فاز پس از راهاندازی اولیه (hci_powered_update_sync) پارامترهای زمان اجرا مانند SSP، تبلیغات (advertising) و تنظیمات پویش (scan) را پیکربندی میکند.
برای دستگاههای پیکربندینشده (مانند کنترلکنندههایی که نیاز به بارگذاری سفتافزار یا برنامهریزی آدرس BD دارند)، تنها یک مرحله ۰ حداقلی برای شناسایی سختافزار اجرا میشود.
مرحله ۰: بازنشانی و شناسایی پایه (فقط دستگاههای پیکربندینشده) (Stage 0: Reset and Basic Identity (Unconfigured Only))
این مرحله تنها برای کنترلکنندههای پیکربندینشدهای اجرا میشود که پیش از راهاندازی اولیه کامل نیاز به برپایی (setup) دارند.
دستورات ارسالی:
| دستور HCI | هدف |
| HCI_Reset | بازنشانی کنترلکننده (در صورت وجود رفتارهای خاص سختافزاری RESET_ON_CLOSE نادیده گرفته میشود) |
| HCI_Read_Local_Version_Information | خواندن نسخه سختافزار/سفتافزار |
| HCI_Read_BD_ADDR | خواندن آدرس بلوتوث کنترلکننده |
مرحله ۱: بازنشانی و خواندن ویژگیهای محلی (Stage 1: Reset and Read Local Features)
کنترلکننده را بازنشانی کرده و اطلاعات هویتی و قابلیتهای اصلی را میخواند.
دستورات ارسالی:
| دستور HCI | هدف |
| HCI_Reset | بازنشانی کنترلکننده |
| HCI_Read_Local_Supported_Features | خواندن بیتماسک ویژگیهای LMP (شامل BR/EDR ،LE ،SSP و غیره) |
| HCI_Read_Local_Version_Information | خواندن نسخه HCI، نسخه LMP و سازنده |
| HCI_Read_BD_ADDR | خواندن آدرس عمومی بلوتوث |
مرحله ۲: خواندن قابلیتها و پیکربندی اولیه (Stage 2: Read Capabilities and Setup)
قابلیتهای تفصیلی را میخواند، ویژگیهای اصلی را فعال میکند و اندازههای بافر را میخواند. این مرحله شامل سه فاز است: دستورات مشترک، دستورات ویژه BR/EDR و دستورات ویژه LE.
دستورات مشترک (Common Commands)
| دستور HCI | هدف |
| HCI_Read_Local_Supported_Commands | خواندن بیتماسک دستورات پشتیبانیشده (HCI 1.2 به بالا) |
| HCI_Write_Simple_Pairing_Mode (enable) | فعالسازی SSP در صورت پشتیبانی و پیکربندی |
| HCI_Write_Extended_Inquiry_Response (clear) | پاکسازی دادههای EIR در صورت غیرفعال بودن SSP |
| HCI_Write_Inquiry_Mode | تنظیم حالت پرسوجو (RSSI یا Extended، بر اساس ویژگیها) |
| HCI_Read_Inquiry_Response_Transmit_Power_Level | خواندن توان ارسال پرسوجو (TX) در صورت پشتیبانی |
| HCI_Read_Local_Extended_Features (page 1) | خواندن صفحه ۱ از ویژگیهای گسترشیافته (میزبان SSP، میزبان LE و غیره) |
| HCI_Write_Authentication_Enable | همگامسازی وضعیت احراز هویت با پرچم LINK_SECURITY |
دستورات BR/EDR (در صورت پشتیبانی از BR/EDR) (BR/EDR Commands)
| دستور HCI | هدف |
| HCI_Read_Buffer_Size | خواندن اندازه و تعداد بافرهای ACL/SCO |
| HCI_Read_Class_of_Device | خواندن رده فعلی دستگاه |
| HCI_Read_Local_Name | خواندن نام محلی ذخیرهشده |
| HCI_Read_Voice_Setting | خواندن تنظیمات صوتی SCO (در صورت پشتیبانی) |
| HCI_Read_Number_of_Supported_IAC | خواندن تعداد کدهای دسترسی پرسوجو (IAC) پشتیبانیشده |
| HCI_Read_Current_IAC_LAP | خواندن مقادیر فعلی IAC LAP |
| HCI_Set_Event_Filter (clear all) | پاکسازی تمام فیلترهای رویداد ذخیرهشده |
| HCI_Write_Connection_Accept_Timeout | تنظیم مهلت زمانی پذیرش اتصال (حدود ۲۰ ثانیه) |
| HCI_Write_Synchronous_Flow_Control_Enable | فعالسازی کنترل جریان SCO در صورت پشتیبانی |
دستورات LE (در صورت پشتیبانی از LE) (LE Commands)
| دستور HCI | هدف |
| LE_Read_Local_Supported_Features | خواندن بیتماسک ویژگیهای LE |
| LE_Read_All_Local_Supported_Features | خواندن ویژگیهای گسترشیافته LE (در صورت پشتیبانی) |
| LE_Read_Buffer_Size [v2] or [v1] | خواندن اندازههای بافر LE ACL (و ISO)؛ نسخه v2 در صورت پشتیبانی از ISO استفاده میشود |
| LE_Read_Supported_States | خواندن جدول ترکیبات حالتهای LE |
مرحله ۳: ماسکهای رویداد، سیاست پیوند و ویژگیها (Stage 3: Event Masks, Link Policy, and Features)
تعیین میکند که کنترلکننده کدام رویدادها را باید گزارش دهد، سیاست پیوند را تنظیم میکند و صفحات ویژگیهای گسترشیافته را میخواند. این طولانیترین مرحله است.
ماسکهای رویداد و سیاست پیوند (Event Masks and Link Policy)
| دستور HCI | هدف |
| HCI_Set_Event_Mask | پیکربندی ماسک رویداد اصلی بر اساس قابلیتهای کنترلکننده |
| HCI_Read_Stored_Link_Key | خواندن تمام کلیدهای پیوند ذخیرهشده |
| HCI_Write_Default_Link_Policy_Settings | فعالسازی تعویض نقش، حالتهای hold ،sniff و park بر اساس ویژگیهای LMP |
| HCI_Read_Page_Scan_Activity | خواندن بازه و پنجره زمانی پویش صفحه |
| HCI_Read_Default_Erroneous_Data_Reporting | خواندن وضعیت گزارش دادههای خطا (برای گفتار باند پهن) |
| HCI_Read_Page_Scan_Type | خواندن نوع پویش صفحه (استاندارد یا درهمبافته) |
| HCI_Read_Local_Extended_Features (pages 2..N) | خواندن تمام صفحات باقیمانده از ویژگیهای گسترشیافته |
جزئیات ماسک رویداد: برای کنترلکنندههای دومنظوره، هسته رویدادهای مربوط به نتایج پرسوجو (RSSI و گسترشیافته)، SSP (قابلیت IO، تأیید کاربر، کلید عبور)، اتصالات همگام، sniff subrating، تازهسازی رمزنگاری، نظارت پیوند و فرا-رویدادهای LE را فعال میکند. برای کنترلکنندههای صرفاً LE، یک ماسک حداقلی تنها شامل تکمیل دستور، خطاهای سختافزاری، قطع اتصال و تغییرات رمزنگاری میشود.
ماسک رویداد و قابلیتهای LE (LE Event Mask and Capabilities)
| دستور HCI | هدف |
| LE_Set_Event_Mask | پیکربندی زیر-رویدادهای LE که باید گزارش شوند |
| LE_Read_Advertising_Channel_Tx_Power | خواندن توان ارسال تبلیغات (فقط تبلیغات سنتی) |
| LE_Read_Transmit_Power | خواندن محدوده حداقل/حداکثر توان ارسال |
| LE_Read_Accept_List_Size | خواندن ظرفیت فهرست پذیرش پالایه |
| LE_Clear_Accept_List | پاکسازی فهرست پذیرش پالایه |
| LE_Read_Resolving_List_Size | خواندن ظرفیت فهرست حل آدرس (LL Privacy) |
| LE_Clear_Resolving_List | پاکسازی فهرست حل آدرس |
| LE_Set_Resolvable_Private_Address_Timeout | تنظیم مهلت زمانی چرخش RPA |
| LE_Read_Maximum_Data_Length | خواندن حداکثر بایتهای TX/RX و زمان (گسترش طول داده) |
| LE_Read_Suggested_Default_Data_Length | خواندن طول داده پیشفرض فعلی |
| LE_Read_Number_of_Supported_Advertising_Sets | خواندن ظرفیت مجموعههای تبلیغات گسترشیافته |
| HCI_Write_LE_Host_Supported | اطلاعرسانی پشتیبانی میزبان از LE به کنترلکننده (فقط حالت دومنظوره) |
| LE_Set_Host_Feature | فعالسازی CIS Central (بیت ۳۲) و/یا Channel Sounding (بیت ۴۷) |
جزئیات ماسک رویداد LE: هسته زیر-رویدادهای LE را بر اساس قابلیتها فعال میکند: تکمیل اتصال (در صورت وجود، پیشرفته)، گزارشهای تبلیغات (در صورت وجود، گسترشیافته)، درخواست کلید بلندمدت، درخواست پارامترهای اتصال، تغییر طول داده، بهروزرسانی PHY، الگوریتم انتخاب کانال، رویدادهای تبلیغات دورهای، برقراری/درخواست CIS (در صورت پشتیبانی از CIS)، ایجاد/همگامسازی/اطلاعات BIG (در صورت پشتیبانی از BIS) و رویدادهای کاوش کانال (در صورت پشتیبانی از CS).
مرحله ۴: پیکربندی نهایی (Stage 4: Final Configuration)
پیکربندی نهایی را انجام میدهد: کلیدهای بیاستفاده را حذف میکند، صفحه ۲ ماسک رویداد را تنظیم میکند، اطلاعات کدک را میخواند، اتصالات امن (Secure Connections) را فعال میکند و پیشفرضهای طول داده و PHY در LE را پیکربندی مینماید.
کلیدها، کدکها و اتصالات امن (Keys, Codecs, and Secure Connections)
| دستور HCI | هدف |
| HCI_Delete_Stored_Link_Key (all) | حذف تمام کلیدهای پیوند ذخیرهشده از کنترلکننده |
| HCI_Set_Event_Mask_Page_2 | فعالسازی رویدادهای صفحه ۲ (مهلت زمانی بار داده احراز هویتشده و غیره) |
| HCI_Read_Local_Supported_Codecs [v2] or [v1] | خواندن شناسههای کدک پشتیبانیشده؛ نسخه v2 شامل اطلاعات نوع انتقال است |
| HCI_Read_Local_Pairing_Options | خواندن گزینههای پیشفرض جفتسازی (حداکثر اندازه کلید رمزنگاری) |
| HCI_Get_MWS_Transport_Layer_Configuration | خواندن پیکربندی همزیستی MWS در صورت پشتیبانی |
| HCI_Read_Synchronization_Train_Parameters | خواندن پارامترهای قطار همگامسازی (Connectionless Peripheral Broadcast) |
| HCI_Write_Secure_Connections_Support (enable) | فعالسازی اتصالات امن (Secure Connections) در صورت فعال بودن SSP |
| HCI_Write_Default_Erroneous_Data_Reporting | فعالسازی/غیرفعالسازی بر اساس تنظیم گفتار باند پهن |
طول داده LE و پیشفرضهای PHY (LE Data Length and PHY Defaults)
| دستور HCI | هدف |
| LE_Write_Suggested_Default_Data_Length | تنظیم بایتها/زمان پیشفرض TX برای اتصالات جدید |
| LE_Set_Default_PHY | تنظیم لایه فیزیکی (PHY) ترجیحی (همواره 1M؛ و 2M و Coded در صورت پشتیبانی) |
پس از راهاندازی اولیه (Post-Initialization)
پس از تکمیل هر چهار مرحله، hci_powered_update_sync برای اعمال پیکربندی زمان اجرا اجرا میشود:
| اقدام | هدف |
| HCI_Write_Simple_Pairing_Mode | فعالسازی مجدد SSP + Secure Connections در صورت پیکربندی |
| HCI_Write_LE_Host_Supported | همگامسازی وضعیت پشتیبانی میزبان از LE |
| برپایی تبلیغات LE | پیکربندی پارامترها و دادههای تبلیغات |
| HCI_Write_Authentication_Enable | همگامسازی وضعیت فعال بودن احراز هویت |
| بهروزرسانیهای پویش/رده/نام/EIR | پیکربندی پویش صفحه، رده دستگاه، نام محلی و دادههای EIR |
| LE_Set_Random_Address | تنظیم آدرس تصادفی ایستا در صورت عدم وجود آدرس عمومی |
خواندن دنباله راهاندازی اولیه در رهگیری بستهها (Reading the Init Sequence in a Trace)
هنگام بررسی یک رهگیری btsnoop، بلوک راهاندازی اولیه نخستین موردی است که پس از باز شدن کنترلکننده دیده میشود. رهگیری یک کنترلکننده معمول دومنظوره با موارد زیر آغاز میشود:
< HCI Command: Reset > HCI Event: Command Complete (Reset) < HCI Command: Read Local Supported Features > HCI Event: Command Complete (Read Local Supported Features) < HCI Command: Read Local Version Information > HCI Event: Command Complete (Read Local Version Information) < HCI Command: Read BD ADDR > HCI Event: Command Complete (Read BD ADDR) ... [Stage 2-4 commands follow]
نکات کلیدی که باید به دنبال آنها بود:
- دستورات مفقود (Missing commands): اگر دستورات مورد انتظار وجود نداشته باشند، ممکن است کنترلکننده از قابلیت مربوطه پشتیبانی نکند. برای نمونه، نبود LE_Read_Buffer_Size بدین معناست که کنترلکننده صرفاً از BR/EDR پشتیبانی میکند.
- شکست دستورات (Command failures): مقدار Status غیر از 0x00 در یک رویداد Command Complete در طول راهاندازی اولیه معمولاً نشاندهنده نقص در کنترلکننده یا یک قابلیت پشتیبانینشده است. هسته اغلب این موارد را با ملایمت مدیریت میکند، اما خطاهای مداوم ممکن است مانع از کارکرد آداپتور شوند.
- اندازههای بافر (Buffer sizes): مقادیر بازگرداندهشده توسط Read_Buffer_Size و LE_Read_Buffer_Size تعیین میکنند که کنترلکننده چه تعداد بسته در حال انتقال (in-flight) را میتواند نگه دارد. تعداد کم بافرها میتواند باعث بروز مشکلات در نرخ تبادل داده (throughput) شود.
- بیتهای ویژگی (Feature bits): پاسخ Read_Local_Supported_Features مشخص میکند که کنترلکننده از چه مواردی پشتیبانی میکند (مانند LE ،SSP، eSCO و غیره). این موارد را با دستورات بعدی مطابقت دهید — هسته تنها برای قابلیتهایی دستور ارسال میکند که کنترلکننده پشتیبانی از آنها را گزارش داده باشد.
- ماسک رویداد (Event mask): دستور Set_Event_Mask دقیقاً نشان میدهد که میزبان مایل به دریافت کدام رویدادها است. اگر رویداد مورد انتظاری هرگز در رهگیری ظاهر نشود، بررسی کنید که آیا در ماسک فعال شده بوده است یا خیر.
- کنترلکنندههای صرفاً LE (LE-only controllers): این کنترلکنندهها تمام دستورات BR/EDR (مانند Read_Buffer_Size، Read_Local_Name، سیاست پیوند و غیره) را نادیده میگیرند و از یک ماسک رویداد حداقلی استفاده میکنند. رهگیری آنها به وضوح کوتاهتر خواهد بود.
- دستورات سازنده (Vendor commands): برخی کنترلکنندهها (Intel، Broadcom ،Qualcomm ،Realtek ،MediaTek) دستورات HCI ویژه سازنده را میان مراحل جهت دانلود سفتافزار، پیکربندی یا اعمال وصله درج میکنند. این دستورات با گروههای آپکد 0x3F (سازنده) نمایش داده میشوند و مختص درایور هستند.
ردیابی اتصال (CONNECTION TRACKING)
پروتکل HCI از هندلهای اتصال (connection handles) (اعداد صحیح ۱۶ بیتی) برای شناسایی اتصالات مجزا استفاده میکند. درک نحوه نگاشت هندلها به دستگاهها برای خواندن رهگیریها ضروری است.
انواع هندل (Handle Types)
انواع مختلف اتصال از محدودههای هندل متفاوتی استفاده میکنند، اما این محدودهها مختص کنترلکننده (controller-specific) هستند و استانداردسازی نشدهاند. نوع اتصال را میتوان با بررسی رویدادی که هندل را ایجاد کرده است، مشخص کرد:
| نوع (Type) | رویداد ایجاد (Creation Event) | توضیحات (Description) |
| BR/EDR ACL | Connection Complete | اتصال داده بلوتوث کلاسیک |
| LE ACL | LE (Enhanced) Connection Complete | اتصال داده بلوتوث کممصرف (LE) |
| CIS | LE CIS Established | جریان همگام متصل (LE Audio) |
| BIS | LE BIG Complete | جریان همگام همگانی (LE Audio) |
| SCO/eSCO | Synchronous Connection Complete | اتصال همگام صدا/صوتی (کلاسیک) |
یک دستگاه واحد ممکن است به طور همزمان چندین هندل داشته باشد. به عنوان مثال، یک دستگاه LE Audio دارای یک هندل LE ACL برای ترافیک کنترلی و یک یا چند هندل CIS برای جریانهای صوتی خواهد بود. رویداد LE CIS Established شامل هندل اتصال ACL است که CIS به آن مرتبط شده است.
ردیابی بافر کنترلکننده (Controller Buffer Tracking)
ردیابی بافر ممکن است یک نشانگر را در کروشه نشان دهد:
< ACL: Handle 2048 [1/6] flags 0x00 dlen 16
عبارت [1/6] به این معنی است که این اسلات بافر ۱ از ۶ بافر ACL در دسترس کنترلکننده است. این نشاندهنده کنترل جریان HCI در سمت میزبان است: میزبان ردیابی میکند که کنترلکننده چه تعداد بافر در دسترس دارد و مصرف فعلی را نشان میدهد. هنگامی که کنترلکننده رویدادهای Number of Completed Packets را ارسال میکند، بافرها آزاد شده و این شمارش کاهش مییابد.
کدهای خطا و دلایل قطع اتصال HCI (HCI ERROR AND DISCONNECT REASON CODES)
کدهای وضعیت و دلایل قطع اتصال در HCI از یک فضای کد یکسان استفاده میکنند. این کدها در فیلدهای Status: و Reason: در سراسر رهگیری ظاهر میشوند. ابزار btmon آنها را به صورت خودکار رمزگشایی میکند، اما مقادیر هگزادسیمال برای جستجو و فیلتر کردن مفید هستند.
دلایل متداول قطع اتصال (Common Disconnect Reasons)
| کد (Code) | نام (Name) | مفهوم تشخیصی (Diagnostic Meaning) |
| 0x05 | Authentication Failure | راهاندازی احراز هویت یا رمزگذاری ناموفق بود. کلید ممکن است منسوخ شده باشد یا پایگاههای داده امنیتی دستگاهها با یکدیگر همخوانی نداشته باشند. |
| 0x08 | Connection Timeout | تایمر نظارت (supervision timer) منقضی شد. دستگاه راه دور از محدوده خارج شده یا پاسخ نداده است. این یک قطع ارتباط پیوند رادیویی (RF) است. |
| 0x13 | Remote User Terminated Connection | دستگاه راه دور عمداً اتصال را قطع کرد. این حالت قطع اتصال عادی و منظم (graceful) است. |
| 0x14 | Remote Device Terminated due to Low Resources | منابع دستگاه راه دور (حافظه، اسلاتهای اتصال) به پایان رسید. |
| 0x15 | Remote Device Terminated due to Power Off | دستگاه راه دور در حال خاموش شدن است. |
| 0x16 | Connection Terminated By Local Host | پشته محلی BlueZ عمداً اتصال را قطع کرد. این حالت هنگامی که bluetoothd قطع اتصال را آغاز میکند عادی است. |
| 0x1f | Unspecified Error | خطای عمومی و نامشخص. اغلب نشاندهنده مشکل میانافزار/سفتافزار (firmware) است. |
| 0x22 | LMP/LL Response Timeout | مهلت زمانی رویه لایه پیوند (Link Layer) به پایان رسید. دستگاه راه دور ارسال پاسخ به PDUهای کنترلی LL را متوقف کرد. |
| 0x28 | Instant Passed | یک عملیات حساس به زمان از مهلت مقرر گذشت. اغلب در بهروزرسانیهای پارامتر اتصال دیده میشود. |
| 0x2f | Insufficient Security | سطح امنیتی مورد نیاز (رمزگذاری، حفاظت MITM) برآورده نشد. |
| 0x3b | Unacceptable Connection Parameters | دستگاه راه دور بهروزرسانی پارامترهای اتصال را رد کرد. |
| 0x3d | Connection Terminated due to MIC Failure | بررسی یکپارچگی رمزگذاری (MIC) ناموفق بود. عدم تطابق یا خرابی احتمالی کلید. |
| 0x3e | Connection Failed to be Established | تلاش برای برقراری اتصال کاملاً ناموفق بود (به عنوان مثال، دستگاه راه دور به درخواستهای اتصال پاسخ نداد). |
| 0x3f | MAC Connection Failed | شکست اتصال در سطح MAC. |
| 0x44 | Operation Cancelled by Host | میزبان عملیات را پیش از تکمیل لغو کرد. |
جدول کامل کدهای خطا (Full Error Code Table)
مجموعه کامل کدهای خطای HCI (از 0x00 تا 0x45) در مشخصات هسته بلوتوث (Bluetooth Core Specification)، جلد ۱، بخش F تعریف شده است. ابزار btmon تمام آنها را به طور خودکار در فیلدهای Status: و Reason: رمزگشایی میکند. نگاشت کدهای منبع در monitor/packet.c (error2str_table) قرار دارد.
بازسازی پایگاهداده GATT از رهگیریهای SNOOP (RECONSTRUCTING A GATT DATABASE FROM SNOOP TRACES)
یک رهگیری btsnoop شامل تبادل کامل پروتکل ATT است که توسط کلاینتها و سرورهای GATT برای کشف سرویسهای یکدیگر استفاده میشود. با خواندن درخواستها و پاسخهای کشف، بازسازی پایگاهداده کامل GATT یک دستگاه راه دور -- حتی بدون دسترسی به خود دستگاه -- امکانپذیر است.
این بخش، رویه کشف GATT و نحوه نمایش هر عملیات ATT را در خروجی btmon توضیح میدهد.
نمای کلی کشف GATT (Overview of GATT Discovery)
کشف GATT یک فرایند چندمرحلهای است که در آن کلاینت با استفاده از عملیات پروتکل ATT، از پایگاهداده صفتها/ویژگیهای (attribute) سرور پرسوجو میکند. این فازها عبارتند از:
- 1.
- کشف سرویسهای اصلی (Primary Service Discovery) -- یافتن تمام سرویسهای اصلی و محدودههای هندل آنها.
- 2.
- کشف سرویسهای ثانویه (Secondary Service Discovery) -- یافتن هرگونه سرویس ثانویه (که صرفاً گنجانده شدهاند).
- 3.
- کشف سرویسهای گنجاندهشده (Included Service Discovery) -- یافتن سرویسهایی که سرویسهای دیگر را در بر دارند.
- 4.
- کشف مشخصهها (Characteristic Discovery) -- یافتن تمام مشخصهها در هر سرویس.
- 5.
- کشف توصیفکنندهها (Descriptor Discovery) -- یافتن تمام توصیفکنندهها برای هر مشخصه.
- 6.
- خواندن مقدار مشخصه (Characteristic Value Reading) -- خواندن مقادیر مشخصههای قابل خواندن.
هر فاز از یک عملیات ATT خاص استفاده کرده و یک الگوی درخواست/پاسخ را در رهگیری ایجاد میکند. کلاینت هر درخواست را با پیش بردن محدودههای هندل تکرار میکند تا زمانی که سرور با Attribute Not Found پاسخ دهد که نشاندهنده پایان آن فاز است.
فاز ۱: کشف سرویسهای اصلی (خواندن بر اساس نوع گروه) (Phase 1: Primary Service Discovery (Read By Group Type))
کلاینت، سرویسهای اصلی را با استفاده از Read By Group Type Request با شناسه یکتای UUID مربوط به Primary Service (مقدار 0x2800) به عنوان نوع گروه کشف میکند.
درخواست (Request):
< ACL Data TX: Handle 2048 flags 0x00 dlen 11 #516 [hci0] 0.124726
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
اولین درخواست همیشه از هندل 0x0001 آغاز میشود و تا 0xffff (کل فضای هندل) را جستجو میکند.
پاسخ (Response):
> ACL Data RX: Handle 2048 flags 0x02 dlen 42 #523 [hci0] 0.240151
ATT: Read By Group Type Response (0x11) len 37
Attribute data length: 6
Attribute group list: 6 entries
Handle range: 0x0001-0x0009
UUID: Generic Access Profile (0x1800)
Handle range: 0x000a-0x0011
UUID: Generic Attribute Profile (0x1801)
Handle range: 0x0012-0x0014
UUID: Device Information (0x180a)
Handle range: 0x0015-0x0039
UUID: Generic Telephony Bearer (0x184c)
Handle range: 0x003a-0x0059
UUID: Generic Media Control (0x1849)
Handle range: 0x005a-0x005c
UUID: Telephony and Media Audio (0x1855)
هر مدخل موارد زیر را ارائه میدهد:
- محدوده هندل (Handle range) -- هندل شروع و پایان سرویس. تمام صفتها/ویژگیهای متعلق به این سرویس (مشخصهها، توصیفکنندهها) دارای هندلهایی در این محدوده هستند.
- UUID -- شناسه یکتای سرویس. شناسههای استاندارد ۱۶ بیتی UUID همراه با نام آنها نشان داده میشوند (مانند Generic Access Profile). شناسههای ۱۲۸ بیتی اختصاصی سازنده (vendor-specific) به صورت رشتههای کامل UUID ظاهر میشوند.
کلاینت با ارسال درخواستی دیگر که از بعد از آخرین هندل موجود در پاسخ آغاز میشود، ادامه میدهد:
< ACL Data TX: Handle 2048 flags 0x00 dlen 11 #525 [hci0] 0.240641
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x005d-0xffff
Attribute group type: Primary Service (0x2800)
این روند تا زمانی که سرور با Attribute Not Found پاسخ دهد ادامه مییابد:
> ACL Data RX: Handle 2048 flags 0x02 dlen 9 #532 [hci0] 0.360069
ATT: Error Response (0x01) len 4
Read By Group Type Request (0x10)
Handle: 0x005d
Error: Attribute Not Found (0x0a)
این خطا نشان میدهد که فراتر از هندل 0x005d هیچ سرویس اصلی دیگری وجود ندارد. کلاینت اکنون فهرست کاملی از سرویسهای اصلی را در اختیار دارد.
نکته:
فاز ۲: کشف سرویسهای ثانویه (Phase 2: Secondary Service Discovery)
پس از سرویسهای اصلی، کلاینت ممکن است سرویسهای ثانویه را با استفاده از همان Read By Group Type Request اما با شناسه یکتای UUID مربوط به Secondary Service (مقدار 0x2801) کشف کند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 11 #534 [hci0] 0.360752
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Secondary Service (0x2801)
اگر هیچ سرویس ثانویهای وجود نداشته باشد، سرور با Attribute Not Found پاسخ میدهد. سرویسهای ثانویه مستقیماً برای کلاینتها قابل دسترسی نیستند -- آنها فقط از طریق ارجاعات گنجاندن (include) از سرویسهای اصلی قابل دستیابی هستند.
فاز ۳: کشف سرویسهای گنجاندهشده (خواندن بر اساس نوع) (Phase 3: Included Service Discovery (Read By Type))
برای کشف اینکه کدام سرویسها شامل سرویسهای دیگر میشوند، کلاینت از Read By Type Request با شناسه UUID مربوط به Include (مقدار 0x2802) استفاده میکند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 11 #540 [hci0] 0.480731
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0001-0x005c
Attribute type: Include (0x2802)
محدوده هندل معمولاً کل پایگاهداده کشفشده را در بر میگیرد. هر اعلان گنجاندن (include declaration) در پاسخ، سرویسی را مشخص میکند که توسط سرویسِ در بر گیرنده آن هندل، گنجانده شده است.
فاز ۴: کشف مشخصهها (خواندن بر اساس نوع) (Phase 4: Characteristic Discovery (Read By Type))
برای هر سرویس، کلاینت مشخصههای آن را با استفاده از Read By Type Request با شناسه UUID مربوط به Characteristic (مقدار 0x2803) کشف میکند. محدوده هندل به محدوده هندل سرویس محدود میشود.
درخواست (Request):
> ACL Data RX: Handle 2048 flags 0x02 dlen 11 #531 [hci0] 0.360063
ATT: Read By Type Request (0x08) len 6
Handle range: 0x0008-0x0011
Attribute type: Characteristic (0x2803)
پاسخ (Response):
< ACL Data TX: Handle 2048 flags 0x00 dlen 27 #533 [hci0] 0.360714
ATT: Read By Type Response (0x09) len 22
Attribute data length: 7
Attribute data list: 3 entries
Handle: 0x0009
Value[5]: 200a00052a
Properties: 0x20
Indicate (0x20)
Value Handle: 0x000a
Value UUID: Service Changed (0x2a05)
Handle: 0x000c
Value[5]: 0a0d00292b
Properties: 0x0a
Read (0x02)
Write (0x08)
Value Handle: 0x000d
Value UUID: Client Supported Features (0x2b29)
Handle: 0x000e
Value[5]: 020f002a2b
Properties: 0x02
Read (0x02)
Value Handle: 0x000f
Value UUID: Database Hash (0x2b2a)
هر مدخل مشخصه موارد زیر را ارائه میدهد:
- Handle -- هندل صفتِ اعلان مشخصه (characteristic declaration attribute).
- Properties -- یک ماسک
بیتی (bitmask) که
عملیات
پشتیبانیشده
را مشخص
میکند:
بیت (Bit) ویژگی (Property) توضیحات (Description) 0x01 Broadcast میتواند در دادههای تبلیغاتی (advertising) پخش همگانی شود 0x02 Read قابل خواندن است 0x04 Write Without Response بدون تأییدیه قابل نوشتن است 0x08 Write همراه با تأییدیه قابل نوشتن است 0x10 Notify سرور میتواند اعلانها (notifications) را ارسال کند 0x20 Indicate سرور میتواند نشانهها (indications) را ارسال کند 0x40 Authenticated Signed Writes از دستورات نوشتن امضاشده پشتیبانی میکند 0x80 Extended Properties دارای توصیفکننده ویژگیهای گسترشیافته است - Value Handle -- هندلی که مقدار مشخصه در آن ذخیره میشود (همیشه برابر با هندل اعلان + ۱).
- Value UUID -- شناسه یکتای UUID که نوع مشخصه را مشخص میکند.
کلاینت با پیش بردن محدودههای هندل ادامه میدهد تا زمانی که Attribute Not Found را دریافت کند:
> ACL Data RX: Handle 2048 flags 0x02 dlen 9 #572 [hci0] 1.200228
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x005c
Error: Attribute Not Found (0x0a)
فاز ۵: کشف توصیفکنندهها (یافتن اطلاعات) (Phase 5: Descriptor Discovery (Find Information))
توصیفکنندهها هندلهای بین هندل مقدار یک مشخصه و اعلان مشخصه بعدی (یا پایان سرویس) را اشغال میکنند. کلاینت آنها را با استفاده از Find Information Request کشف میکند.
درخواست (Request):
> ACL Data RX: Handle 2048 flags 0x02 dlen 9 #556 [hci0] 0.959965
ATT: Find Information Request (0x04) len 4
Handle range: 0x000b-0x000b
محدوده هندل، فاصله بین هندل مقدار مشخصه و هندل اعلان مشخصه بعدی را پوشش میدهد.
پاسخ (Response):
< ACL Data TX: Handle 2048 flags 0x00 dlen 10 #561 [hci0] 0.961049
ATT: Find Information Response (0x05) len 5
Format: UUID-16 (0x01)
Handle: 0x000b
UUID: Client Characteristic Configuration (0x2902)
شناسههای متداول توصیفکننده (Descriptor UUIDs):
| UUID | نام (Name) | هدف / کاربرد (Purpose) |
| 0x2900 | Characteristic Extended Properties | بیتهای ویژگیهای اضافی |
| 0x2901 | Characteristic User Description | رشته توضیحات خوانا برای انسان |
| 0x2902 | Client Characteristic Configuration (CCC) | فعال/غیرفعالسازی اعلانها یا نشانهها |
| 0x2903 | Server Characteristic Configuration | پیکربندی پخش همگانی در سمت سرور |
| 0x2904 | Characteristic Presentation Format | قالب داده، نما و واحد |
فاز ۶: خواندن مقادیر مشخصه (Phase 6: Reading Characteristic Values)
پس از کشف، کلاینت میتواند مقادیر مشخصهها را با استفاده از Read Request بخواند:
> ACL Data RX: Handle 2048 flags 0x02 dlen 7 #577 [hci0] 1.380203
ATT: Read Request (0x0a) len 2
Handle: 0x000f
< ACL Data TX: Handle 2048 flags 0x00 dlen 21 #579 [hci0] 1.380774
ATT: Read Response (0x0b) len 16
Value[16]: a470d508da8751a2a50b79da0250bfda
مقدار Handle در درخواست با هندل مقدار مشخصه از فاز کشف مطابقت دارد. ابزار btmon بایتهای مقدار خام را نمایش میدهد؛ تفسیر آن به شناسه UUID مشخصه بستگی دارد.
یافتن بر اساس نوع و مقدار (جستجوی هدفمند سرویس) (Find By Type Value (Targeted Service Search))
علاوه بر کشف تمام سرویسها، کلاینت میتواند با استفاده از Find By Type Value Request یک شناسه UUID خاص از سرویس را جستجو کند:
> ACL Data RX: Handle 2048 flags 0x02 dlen 13 #513 [hci0] 0.124195
ATT: Find By Type Value Request (0x06) len 8
Handle range: 0x0001-0xffff
Attribute type: Primary Service (0x2800)
UUID: Generic Attribute Profile (0x1801)
< ACL Data TX: Handle 2048 flags 0x00 dlen 9 #515 [hci0] 0.124684
ATT: Find By Type Value Response (0x07) len 4
Handle range: 0x0008-0x0011
این دستور فقط محدوده هندل مربوط به سرویس منطبق را بازمیگرداند، بدون اینکه نیازی به پیمایش تمام سرویسها باشد. اگر سرویس یافت نشود:
< ACL Data TX: Handle 2048 flags 0x00 dlen 9 #524 [hci0] 0.240607
ATT: Error Response (0x01) len 4
Find By Type Value Request (0x06)
Handle: 0x0012
Error: Attribute Not Found (0x0a)
کشف دوطرفه (Bidirectional Discovery)
هر دو دستگاه موجود در یک اتصال میتوانند به طور همزمان به عنوان کلاینت و سرور GATT عمل کنند. در یک رهگیری btsnoop، ممکن است کشف درهمتنیده در هر دو جهت را مشاهده کنید:
- درخواستهای TX (``<``) + پاسخهای RX (``>``) -- دستگاه محلی (که این رهگیری متعلق به آن است) به عنوان کلاینت GATT عمل میکند و در حال کشف سرویسهای دستگاه راه دور است.
- درخواستهای RX (``>``) + پاسخهای TX (``<``) -- دستگاه راه دور به عنوان کلاینت GATT عمل میکند و در حال کشف سرویسهای دستگاه محلی است.
به عنوان مثال، سرور محلی که به عملیات کشف دستگاه راه دور پاسخ میدهد:
> ACL Data RX: Handle 2048 flags 0x02 dlen 11 #584 [hci0] 1.512006
ATT: Read By Group Type Request (0x10) len 6
Handle range: 0x0001-0xffff
Attribute group type: Primary Service (0x2800)
< ACL Data TX: Handle 2048 flags 0x00 dlen 66 #586 [hci0] 1.518778
ATT: Read By Group Type Response (0x11) len 61
Attribute data length: 6
Attribute group list: 10 entries
Handle range: 0x0001-0x0007
UUID: Generic Access Profile (0x1800)
Handle range: 0x0008-0x0011
UUID: Generic Attribute Profile (0x1801)
Handle range: 0x0012-0x0014
UUID: Device Information (0x180a)
Handle range: 0x0015-0x001e
UUID: Coordinated Set Identification (0x1846)
Handle range: 0x001f-0x0020
UUID: Common Audio (0x1853)
Handle range: 0x0021-0x0024
UUID: Microphone Control (0x184d)
Handle range: 0x0041-0x004b
UUID: Volume Control (0x1844)
Handle range: 0x006b-0x0073
UUID: Broadcast Audio Scan (0x184f)
Handle range: 0x0074-0x0086
UUID: Published Audio Capabilities (0x1850)
Handle range: 0x0087-0x0096
UUID: Audio Stream Control (0x184e)
این مورد، پایگاهداده GATT خود دستگاه محلی را از دید دستگاه راه دور نشان میدهد. برای بازسازی پایگاهداده دستگاه راه دور، بر درخواستهای TX و پاسخهای RX تمرکز کنید (دستگاه محلی که به عنوان کلاینت عمل میکند).
ساخت جدول ویژگیها (Building the Attribute Table)
برای بازسازی پایگاهداده GATT، پاسخهای کشف را استخراج کرده و آنها را در یک جدول ساماندهی کنید. با استفاده از رهگیری بالا به عنوان نمونه، دستگاه راه دور در آدرس 00:11:22:33:44:55 شامل موارد زیر است:
سرویسها (Services) (از Read By Group Type Response):
Handle Range UUID Service Name ────────────── ────────────────────────────── ──────────────────────────── 0x0001-0x0009 0x1800 Generic Access Profile 0x000a-0x0011 0x1801 Generic Attribute Profile 0x0012-0x0014 0x180a Device Information 0x0015-0x0039 0x184c Generic Telephony Bearer 0x003a-0x0059 0x1849 Generic Media Control 0x005a-0x005c 0x1855 Telephony and Media Audio
مشخصهها (Characteristics) (از Read By Type Response، در محدوده GAP 0x0001-0x0009):
Handle Value Handle Properties UUID Name ────── ──────────── ────────── ────── ──────────────────────────────── 0x0002 0x0003 Read 0x2a00 Device Name 0x0004 0x0005 Read 0x2a01 Appearance 0x0006 0x0007 Read 0x2a04 Peripheral Preferred Conn Params 0x0008 0x0009 Read 0x2aa6 Central Address Resolution
مشخصهها (Characteristics) (در محدوده GATT 0x000a-0x0011):
Handle Value Handle Properties UUID Name ────── ──────────── ─────────────── ────── ──────────────────────────── 0x000b 0x000c Indicate 0x2a05 Service Changed 0x000e 0x000f Read, Write 0x2b29 Client Supported Features 0x0010 0x0011 Read 0x2b2a Database Hash
توصیفکنندهها (Descriptors) (از Find Information Response):
Handle UUID Name ────── ────── ──────────────────────────────────── 0x000d 0x2902 Client Characteristic Configuration
توصیفکننده CCC در هندل 0x000d به مشخصه Service Changed (با هندل مقدار 0x000c) تعلق دارد، زیرا بین آن هندل مقدار و اعلان مشخصه بعدی در 0x000e قرار گرفته است.
جریان جفتسازی SMP (SMP PAIRING FLOW)
پروتکل مدیریت امنیت (SMP یا Security Manager Protocol) فرآیند جفتسازی، تولید کلید و توزیع کلید را بین دستگاههای بلوتوث مدیریت میکند. ترافیک SMP درون L2CAP روی شناسه کانال ثابت (CID) مقدار 0x0006 (برای LE) یا CID 0x0007 (برای BR/EDR) ظاهر میشود. ابزار btmon تمام عملیاتهای SMP را به صورت خودکار رمزگشایی میکند.
فازهای جفتسازی (Pairing Phases)
جفتسازی SMP در سه فاز انجام میشود. هر فاز یک الگوی متمایز را در خروجی btmon ایجاد میکند.
فاز ۱: تبادل ویژگیها (Phase 1: Feature Exchange)
جفتسازی زمانی آغاز میشود که یک دستگاه درخواست امنیت (Security Request) ارسال کند (دستگاه جانبی / peripheral) یا میزبان مستقیماً جفتسازی را آغاز نماید. آغازگر یک درخواست جفتسازی (Pairing Request) ارسال میکند و پاسخدهنده با یک پاسخ جفتسازی (Pairing Response) پاسخ میدهد:
> ACL Data RX: Handle 2048 flags 0x02 dlen 11 #497 [hci0] 0.026107
SMP: Pairing Request (0x01) len 6
IO capability: NoInputNoOutput (0x03)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, MITM, SC, CT2 (0x2d)
Max encryption key size: 16
Initiator key distribution: IdKey Sign (0x06)
Responder key distribution: IdKey Sign (0x06)
< ACL Data TX: Handle 2048 flags 0x00 dlen 11 #499 [hci0] 0.026894
SMP: Pairing Response (0x02) len 6
IO capability: KeyboardDisplay (0x04)
OOB data: Authentication data not present (0x00)
Authentication requirement: Bonding, SC, CT2 (0x29)
Max encryption key size: 16
Initiator key distribution: IdKey (0x02)
Responder key distribution: IdKey (0x02)
فیلدهای کلیدی جهت بررسی:
- Authentication requirement -- پرچم SC نشاندهنده اتصالات امن (Secure Connections) است. عدم وجود آن به معنی جفتسازی سنتی (Legacy Pairing) است.
- IO capability -- مدل ارتباط (Just Works، Passkey Entry، Numeric Comparison، OOB) را تعیین میکند.
- Key distribution -- کلیدهایی که هر طرف پس از برقراری رمزنگاری ارسال خواهد کرد. IdKey = کلید تفکیک هویت (IRK)، EncKey = کلید بلندمدت (LTK، فقط در جفتسازی سنتی)، Sign = کلید CSRK.
فاز ۲: احراز هویت (اتصالات امن - Secure Connections)
برای جفتسازی اتصالات امن (تنظیم بودن پرچم SC)، هر دو دستگاه کلیدهای عمومی را تبادل کرده و سپس تبادل مقادیر confirm/random را انجام میدهند:
> ACL Data RX: Handle 2048 flags 0x02 dlen 69 #501 [hci0] 0.098224
SMP: Pairing Public Key (0x0c) len 64
X: 1a2b3c4d...
Y: 5e6f7a8b...
< ACL Data TX: Handle 2048 flags 0x00 dlen 69 #503 [hci0] 0.148556
SMP: Pairing Public Key (0x0c) len 64
X: 9c8d7e6f...
Y: 0a1b2c3d...
< ACL Data TX: Handle 2048 flags 0x00 dlen 21 #505 [hci0] 0.149003
SMP: Pairing Confirm (0x03) len 16
Confirm value: a1b2c3d4e5f6...
> ACL Data RX: Handle 2048 flags 0x02 dlen 21 #507 [hci0] 0.212884
SMP: Pairing Random (0x04) len 16
Random value: 1122334455...
< ACL Data TX: Handle 2048 flags 0x00 dlen 21 #509 [hci0] 0.213100
SMP: Pairing Random (0x04) len 16
Random value: 6677889900...
> ACL Data RX: Handle 2048 flags 0x02 dlen 21 #511 [hci0] 0.278003
SMP: Pairing DHKey Check (0x0d) len 16
E: aabbccddee...
< ACL Data TX: Handle 2048 flags 0x00 dlen 21 #513 [hci0] 0.278450
SMP: Pairing DHKey Check (0x0d) len 16
E: ffeeddccbb...
پس از بررسی DHKey، آغازگر رمزنگاری را در سطح HCI آغاز میکند:
< HCI Command: LE Start Encryption (0x08|0x0019) plen 28 #515 [hci0] 0.279002
> HCI Event: Encryption Change (0x08) plen 4 #517 [hci0] 0.342556
Status: Success (0x00)
Handle: 2048
Encryption: Enabled with AES-CCM (0x01)
فاز ۲: احراز هویت (جفتسازی سنتی - Legacy Pairing)
جفتسازی سنتی (بدون پرچم SC) تبادل کلید عمومی و بررسی DHKey را نادیده میگیرد. فقط مقادیر Confirm و Random تبادل میشوند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 21 #501 [hci0] 0.098224
SMP: Pairing Confirm (0x03) len 16
Confirm value: ...
> ACL Data RX: Handle 2048 flags 0x02 dlen 21 #503 [hci0] 0.162556
SMP: Pairing Confirm (0x03) len 16
Confirm value: ...
< ACL Data TX: Handle 2048 flags 0x00 dlen 21 #505 [hci0] 0.163003
SMP: Pairing Random (0x04) len 16
Random value: ...
> ACL Data RX: Handle 2048 flags 0x02 dlen 21 #507 [hci0] 0.228884
SMP: Pairing Random (0x04) len 16
Random value: ...
فاز ۳: توزیع کلید (Phase 3: Key Distribution)
پس از برقراری رمزنگاری، هر دستگاه کلیدها را همانطور که در فاز ۱ مذاکره شده بود توزیع میکند:
> ACL Data RX: Handle 2048 flags 0x02 dlen 21 #519 [hci0] 0.343002
SMP: Identity Information (0x08) len 16
Identity resolving key: 00112233445566778899aabbccddeeff
> ACL Data RX: Handle 2048 flags 0x02 dlen 12 #521 [hci0] 0.343556
SMP: Identity Address Information (0x09) len 7
Address type: Public (0x00)
Address: 00:11:22:33:44:55
پیام Identity Address Information آدرس عمومی یا تصادفی ایستا واقعی دستگاه را آشکار میکند (در مقایسه با آدرس خصوصی قابل تفکیک که در طول اتصال استفاده میشود).
برای جفتسازی سنتی (Legacy Pairing)، توزیع کلید LTK نیز ظاهر میشود:
> ACL Data RX: Handle 2048 flags 0x02 dlen 21 #519 [hci0] 0.343002
SMP: Encryption Information (0x06) len 16
Long term key: 00112233...
> ACL Data RX: Handle 2048 flags 0x02 dlen 15 #521 [hci0] 0.343556
SMP: Central Identification (0x07) len 10
EDIV: 0x1234
Rand: 0x0123456789abcdef
شکست در جفتسازی (Pairing Failure)
هنگامی که جفتسازی با شکست مواجه میشود، یکی از دستگاهها یک PDU از نوع Pairing Failed ارسال میکند:
> ACL Data RX: Handle 2048 flags 0x02 dlen 6 #505 [hci0] 0.213002
SMP: Pairing Failed (0x05) len 1
Reason: Authentication requirements (0x03)
دلایل شکست SMP:
| کد | دلیل (Reason) | مفهوم تشخیصی |
| 0x01 | Passkey Entry Failed | کاربر فرآیند را لغو کرد یا کلید عبور (passkey) اشتباه وارد شد |
| 0x02 | OOB Not Available | دادههای OOB انتظار میرفت اما ارائه نشد |
| 0x03 | Authentication Requirements | دستگاهها نمیتوانند روی سطح امنیت به توافق برسند (برای مثال، یکی نیازمند MITM است اما قابلیتهای IO فقط Just Works را مجاز میداند) |
| 0x04 | Confirm Value Failed | بررسی رمزنگاری ناموفق بود؛ احتمال حمله MITM |
| 0x05 | Pairing Not Supported | دستگاه راه دور از جفتسازی پشتیبانی نمیکند |
| 0x06 | Encryption Key Size | عدم امکان توافق بر سر اندازه کلید رمزنگاری |
| 0x07 | Command Not Supported | دستور ناشناخته SMP دریافت شد |
| 0x08 | Unspecified Reason | شکست عمومی و نامشخص |
| 0x09 | Repeated Attempts | تلاشهای جفتسازی محدود شده است (Rate-limited)؛ پیش از تلاش مجدد صبر کنید |
| 0x0a | Invalid Parameters | فیلدهای نامعتبر در دستور SMP |
| 0x0b | DHKey Check Failed | توافق کلید ECDH ناموفق بود (فقط در SC) |
| 0x0c | Numeric Comparison Failed | کاربر مقایسه عددی (Numeric Comparison) را رد کرد |
| 0x0d | BR/EDR Pairing In Progress | جفتسازی کلاسیک از قبل فعال و در حال انجام است |
| 0x0e | Cross-Transport Key Derivation Not Allowed | اشتقاق کلید بینانتقالی (CTKD) توسط خطمشی رد شد |
خودکارسازی تحلیل جفتسازی (Automating Pairing Analysis)
شناسایی تمام تلاشهای جفتسازی:
grep -n "Pairing Request\|Pairing Response\|Pairing Failed\|Pairing Public Key\|DHKey Check" output.txt
بررسی روش جفتسازی (اتصالات امن در مقابل سنتی):
- اگر Pairing Public Key بین Request/Response و Confirm ظاهر شود: اتصالات امن (Secure Connections).
- اگر پس از Request/Response تنها Confirm/Random بیاید: جفتسازی سنتی (Legacy Pairing).
- خط Authentication requirement را برای پرچم SC بررسی کنید.
تشخیص شکستهای جفتسازی:
grep -n "Pairing Failed" output.txt
تطبیق جفتسازی با رمزنگاری:
پس از جفتسازی موفقیتآمیز، انتظار رخداد Encryption Change با Status: Success میرود. جستجو برای:
grep -n "Encryption Change\|Encryption:" output.txt
شناسایی جفتسازی مجدد هنگام اتصال مجدد:
اتصالهای مجدد به یک دستگاه پیوندخورده (bonded) باید Encryption Change را بدون ترافیک SMP (با استفاده از کلیدهای ذخیرهشده) نشان دهند. اگر در هنگام اتصال مجدد، پیام SMP Pairing Request ظاهر شود، پیوند در یکی از طرفین از بین رفته است.
الگوی کامل عیبیابی جفتسازی:
- 1.
- یافتن Pairing Request -- یادداشت کردن handle، قابلیتهای IO و الزامات احراز هویت
- 2.
- یافتن Pairing Response -- مقایسه قابلیتهای IO برای تعیین مدل ارتباط (association model)
- 3.
- بررسی وجود Pairing Failed -- در صورت وجود، کد دلیل علت شکست را مشخص میکند
- 4.
- بررسی Encryption Change با Status: Success -- کامل شدن جفتسازی را تأیید میکند
- 5.
- بررسی وجود Identity Address Information -- آدرس واقعی دستگاه را آشکار میسازد
ردیابی کانال L2CAP (L2CAP CHANNEL TRACKING)
پروتکل L2CAP (Logical Link Control and Adaptation Protocol) چندین کانال منطقی را روی یک اتصال ACL منفرد چندگانهسازی (مالتیپلکس) میکند. ابزار btmon سیگنالینگهای L2CAP را به طور خودکار رمزگشایی کرده و دادهها را بر اساس کانال به رمزگشاهای پروتکلهای لایههای بالاتر هدایت میکند.
کانالهای ثابت (Fixed Channels)
کانالهای ثابت دارای شناسههای کانال (CID) از پیش تعیینشده هستند و برای برقراری نیازی به سیگنالینگ ندارند:
| CID | پروتکل | توضیحات |
| 0x0001 | L2CAP Signaling (BR/EDR) | مدیریت کانال برای اتصالات کلاسیک |
| 0x0002 | Connectionless Reception | دادههای بدون اتصال L2CAP |
| 0x0003 | AMP Manager | کنترل AMP (Alternate MAC/PHY) |
| 0x0004 | ATT | پروتکل ویژگی (عملیاتهای GATT) |
| 0x0005 | L2CAP Signaling (LE) | مدیریت کانال برای اتصالات LE |
| 0x0006 | SMP (LE) | پروتکل مدیریت امنیت (Security Manager Protocol) |
| 0x0007 | SMP (BR/EDR) | مدیریت امنیت روی بستر انتقال کلاسیک |
در خروجی btmon، ترافیک کانالهای ثابت مستقیماً بدون هیچ مقدمه سیگنالینگ L2CAP رمزگشایی میشود. برای نمونه، ATT روی CID 0x0004 به صورت زیر ظاهر میشود:
< ACL Data TX: Handle 2048 flags 0x00 dlen 7 #494 [hci0] 0.004488
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
کانالهای پویا (BR/EDR) (Dynamic Channels (BR/EDR))
بلوتوث کلاسیک از سیگنالینگ L2CAP روی CID 0x0001 برای برقراری کانالهای پویا استفاده میکند. هر کانال توسط یک PSM (Protocol/Service Multiplexer) مشخص میشود که تعیین میکند چه پروتکلی روی آن اجرا شود.
برقراری کانال:
> ACL Data RX: Handle 256 flags 0x02 dlen 16 #142 [hci0] 2.034556
L2CAP: Connection Request (0x02) ident 3 len 4
PSM: 25 (0x0019)
Source CID: 0x0040
< ACL Data TX: Handle 256 flags 0x00 dlen 20 #144 [hci0] 2.035002
L2CAP: Connection Response (0x03) ident 3 len 8
Destination CID: 0x0041
Source CID: 0x0040
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
پس از برقراری اتصال، پیکربندیها تبادل میشوند:
> ACL Data RX: Handle 256 flags 0x02 dlen 20 #146 [hci0] 2.035556
L2CAP: Configure Request (0x04) ident 4 len 8
Destination CID: 0x0041
Flags: 0x0000
Option: MTU (0x01) [2]
MTU: 1024
< ACL Data TX: Handle 256 flags 0x00 dlen 18 #148 [hci0] 2.036003
L2CAP: Configure Response (0x05) ident 4 len 6
Source CID: 0x0040
Flags: 0x0000
Result: Success (0x0000)
نگاشتهای متداول PSM به پروتکل:
| PSM | پروتکل | توضیحات |
| 0x0001 | SDP | پروتکل کشف سرویس (Service Discovery Protocol) |
| 0x0003 | RFCOMM | شبیهسازی درگاه سریال (SPP، HFP و غیره) |
| 0x000f | BNEP | پروتکل کپسولهسازی شبکه بلوتوث (Bluetooth Network Encapsulation Protocol) |
| 0x0017 | AVCTP | انتقال کنترل صوتی/تصویری (AVRCP) |
| 0x0019 | AVDTP | انتقال توزیع صوتی/تصویری (A2DP) |
| 0x001b | AVCTP Browsing | کانال مرورگری AVRCP |
| 0x001f | ATT (BR/EDR) | پروتکل صفت روی بستر سنتی |
| 0x0027 | EATT | پروتکل صفت بهبودیافته (Enhanced Attribute Protocol) |
کانالهای مبتنی بر اعتبار LE (LE Credit-Based Channels)
اتصالات LE از سیگنالینگ L2CAP روی CID 0x0005 برای کانالهای پویا استفاده میکنند. مکانیزم اتصال مبتنی بر اعتبار LE کنترل جریان را فراهم میکند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 18 #600 [hci0] 1.824003
LE L2CAP: LE Connection Request (0x14) ident 1 len 10
PSM: 39 (0x0027)
Source CID: 0x0040
MTU: 517
MPS: 251
Credits: 10
> ACL Data RX: Handle 2048 flags 0x02 dlen 18 #602 [hci0] 1.886556
LE L2CAP: LE Connection Response (0x15) ident 1 len 10
Destination CID: 0x0041
MTU: 517
MPS: 251
Credits: 10
Result: Connection successful (0x0000)
پروتکل EATT (Enhanced ATT) از PSM 0x0027 روی کانالهای مبتنی بر اعتبار LE استفاده میکند تا چندین حامل (bearer) موازی برای ATT فراهم آورد.
بهروزرسانیهای پارامترهای اتصال (Connection Parameter Updates)
دستگاههای جانبی LE (Peripherals) به طور مکرر تغییر پارامترهای اتصال را از طریق سیگنالینگ L2CAP درخواست میکنند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 16 #493 [hci0] 0.003915
LE L2CAP: Connection Parameter Update Request (0x12) ident 1 len 8
Min interval: 24
Max interval: 40
Peripheral latency: 0
Timeout multiplier: 256
> ACL Data RX: Handle 2048 flags 0x02 dlen 10 #495 [hci0] 0.066003
LE L2CAP: Connection Parameter Update Response (0x13) ident 1 len 2
Result: Connection Parameters accepted (0x0000)
نتیجه Connection Parameters rejected (0x0001) به این معنی است که دستگاه مرکزی درخواست را رد کرده است.
خودکارسازی تحلیل L2CAP (Automating L2CAP Analysis)
یافتن تمام موارد برقراری کانال L2CAP:
grep -n "Connection Request\|Connection Response\|LE Connection Request\|LE Connection Response" output.txt
ردیابی استفاده از PSM (مشخص میکند کدام پروتکلها فعال هستند):
grep -n "PSM:" output.txt
یافتن مشکلات بهروزرسانی پارامترهای اتصال:
grep -n "Parameter Update Request\|Parameter Update Response\|Parameters rejected" output.txt
یافتن راهاندازی کانال EATT:
grep -n "PSM: 39\|Enhanced Credit" output.txt
ردیابی یک کانال L2CAP خاص: برای دنبال کردن ترافیک روی یک کانال پویا، شناسههای Source CID و Destination CID را از جفت درخواست/پاسخ اتصال (Connection Request/Response) یادداشت کنید. سپس آن CIDها را در فریمهای داده بعدی جستجو نمایید.
تخمین توان عملیاتی (Throughput Estimation)
حالت --analyze (-a) در btmon، آمار هر کانال شامل توان عملیاتی را محاسبه میکند. برای هر کانال L2CAP موارد زیر گزارش میشود:
- Speed: به صورت bytes * 8 / latency_sum_ms محاسبه میشود که در آن latency_sum_ms مجموع اختلاف زمان بین بستهها (نه مدتزمان واقعی ساعت دیواری / wall-clock) است. این بدان معنی است که فاصلههای بیکاری لحاظ نمیشوند، بنابراین این رقم نشاندهنده نرخ ارسال فعال است تا توان عملیاتی در سطح برنامه کاربردی.
- Min/Avg/Max latency: محدوده زمان بین رسیدن بستهها (inter-arrival time).
خروجی نمونه:
Found TX L2CAP channel with CID 64
PSM 128 (0x0080)
Mode: LE Credit
MTU: 672
MPS: 490
TX packets: 29120/29114
TX Latency: 1-79 msec (~29 msec)
TX size: 494-494 octets (~494 octets)
TX speed: ~571 Kb/s
جزئیات کانال نشاندادهشده در حالت analyze:
- کانالهای ثابت (CID <= 7) نام پروتکل خود را نشان میدهند (مانند ATT، L2CAP Signaling (LE)).
- PSM در هر دو مبنای دهدهی و شانزدهشانزدهی نشان داده میشود.
- Mode از گزینههای Configure Request (در BR/EDR) یا سیگنالینگ LE (مانند Basic، ERTM، LE Credit، Enhanced Credit و غیره) رمزگشایی میشود.
- MTU و MPS از تبادلات سیگنالینگ استخراج میشوند.
نکات و محدودیتهای توان عملیاتی:
- 1.
- مقدار سرعت از مجموع تأخیر بین بستهها به عنوان مخرج کسر استفاده میکند، نه زمان سپریشده واقعی (wall-clock). اگر فرستنده متوقف شود (مثلاً در انتظار اعتبارها (Credits))، دوره بیکاری محاسبه نمیشود که این امر سرعت گزارششده را نسبت به توان عملیاتی کلی بیشتر نشان میدهد.
- 2.
- تأخیر TX از زمان ارسال دستور تا رویداد تکمیل اندازهگیری میشود. تأخیر RX زمان بین رسیدن بستههای متوالی است. این موارد چیزهای متفاوتی را اندازهگیری میکنند، بنابراین سرعتهای TX و RX برای یک کانال مشخص به طور مستقیم با یکدیگر قابل مقایسه نیستند.
- 3.
- برای توان عملیاتی پنجرهای (min/avg/max)، ابزار btsnoop-analyzer از پنجرههای نمونهبرداری ۱ ثانیهای بر حسب زمان واقعی استفاده میکند که دیدگاه واقعبینانهتری از نوسانات پهنای باند در سطح برنامه کاربردی ارائه میدهد.
استخراج خودکار توان عملیاتی از خروجی analyze در btmon:
btmon -a trace.btsnoop 2>/dev/null | grep -E "speed:|Mode:|MTU:|MPS:|PSM"
جریان پروتکل LE AUDIO (LE AUDIO PROTOCOL FLOW)
فناوری LE Audio از یک پشته پروتکل چندلایه استفاده میکند که در ردگیریهای btmon قابل مشاهده است. توالی راهاندازی شامل عملیات ATT روی مشخصههای خاص GATT (از جمله PACS و ASCS) و به دنبال آن مدیریت CIS/BIG در سطح HCI است. ابزار btmon تمام لایهها را بهطور کامل رمزگشایی میکند.
کشف PAC (قابلیتهای صوتی منتشرشده) (PAC Discovery)
پیش از آغاز پخش جریان صوتی (Audio Streaming)، دستگاهها قابلیتهای کدک خود را از طریق سرویس قابلیتهای صوتی منتشرشده (Published Audio Capabilities Service یا PACS) مبادله میکنند. کلاینت مشخصههای PACS را میخواند تا متوجه شود دستگاه راه دور از چه مواردی پشتیبانی میکند.
خواندن PAC مربوط به Sink (قابلیتهای دریافت دستگاه راه دور):
< ACL Data TX: Handle 2048 flags 0x00 dlen 7 #550 [hci0] 0.824003
ATT: Read Request (0x0a) len 2
Handle: 0x0075
> ACL Data RX: Handle 2048 flags 0x02 dlen 30 #552 [hci0] 0.886556
ATT: Read Response (0x0b) len 25
Handle: 0x0075
Number of PAC(s): 1
Codec: LC3 (0x06)
Codec Specific Capabilities: #0
Sampling Frequency: 8000 Hz 16000 Hz 24000 Hz 32000 Hz 48000 Hz
Frame Duration: 7.5 ms 10 ms
Audio Channel Counts: 1
Frame Length: 26 - 240
رکورد PAC قابلیتهای کدک را با استفاده از کدگذاری LTV (طول-نوع-مقدار / Length-Type-Value) نمایش میدهد. فیلدهای کلیدی:
- Codec -- کدک اجباری LE Audio یعنی LC3 (0x06)
- Sampling Frequency -- نرخهای نمونهبرداری پشتیبانیشده (بیتماسک)
- Frame Duration -- مدتزمان فریمهای پشتیبانیشده (۷.۵ میلیثانیه و/یا ۱۰ میلیثانیه)
- Audio Channel Counts -- تعداد کانالهای صوتی پشتیبانیشده
- Frame Length -- حداقل و حداکثر بایتها (اکتتها) در هر فریم کدک
Audio Locations (تخصیص کانال):
> ACL Data RX: Handle 2048 flags 0x02 dlen 9 #554 [hci0] 0.948003
ATT: Read Response (0x0b) len 4
Handle: 0x0077
Location: Front Left
Available Audio Contexts (زمینهها و کاربردهای صوتی موجود):
> ACL Data RX: Handle 2048 flags 0x02 dlen 9 #558 [hci0] 1.012556
ATT: Read Response (0x0b) len 4
Handle: 0x007b
Sink Context: Media Conversational
Source Context: Unspecified
کشف ASE و ماشین وضعیت (ASE Discovery and State Machine)
سرویس کنترل جریان صوتی (Audio Stream Control Service یا ASCS) ماشین وضعیت ASE (نقطه پایانی جریان صوتی / Audio Stream Endpoint) را مدیریت میکند. هر ASE در حین راهاندازی و برچیدن جریان صوتی، از میان مجموعهای مشخص از وضعیتها عبور میکند.
ماشین وضعیت ASE:
Idle ──► Codec Configured ──► QoS Configured ──► Enabling ──► Streaming
│
Idle ◄── Releasing ◄──────── Disabling ◄─────────────────────────┘
اعلان وضعیت ASE (ASE Status notification) (تغییر وضعیت):
> ACL Data RX: Handle 2048 flags 0x02 dlen 20 #580 [hci0] 1.456003
ATT: Handle Value Notification (0x1b) len 15
Handle: 0x0088
ASE ID: 0x01
State: Codec Configured (0x01)
Framing: Unframed PDUs supported (0x00)
PHY: 0x02
LE 2M PHY (0x02)
RTN: 2
Max Transport Latency: 10
Presentation Delay Min: 20000 us
Presentation Delay Max: 40000 us
Preferred Presentation Delay Min: 20000 us
Preferred Presentation Delay Max: 40000 us
Codec: LC3 (0x06)
Sampling Frequency: 48000 Hz
Frame Duration: 10 ms
Audio Channel Allocation: Front Left
Frame Length: 120
عملیاتهای نقطه کنترل ASE (ASE Control Point operations) تغییرات وضعیت را هدایت میکنند. کلاینت برای صدور دستورها، در مشخصه نقطه کنترل ASE مینویسد:
< ACL Data TX: Handle 2048 flags 0x00 dlen 25 #582 [hci0] 1.518003
ATT: Write Request (0x12) len 20
Handle: 0x008b
ASE Control Point: Config Codec (0x01)
ASE ID: 0x01
Target Latency: Low Latency (0x01)
PHY: LE 2M PHY
Codec: LC3 (0x06)
Sampling Frequency: 48000 Hz
Frame Duration: 10 ms
Audio Channel Allocation: Front Left
Frame Length: 120
دستورهای نقطه کنترل ASE (ASE Control Point):
| کد عملیاتی (Opcode) | دستور (Command) | هدف (Purpose) |
| 0x01 | Config Codec | انتخاب کدک و پارامترها (Idle → Codec Configured) |
| 0x02 | Config QoS | تنظیم شناسههای CIG/CIS و پارامترهای کیفیت خدمات QoS (Codec Configured → QoS Configured) |
| 0x03 | Enable | راهاندازی ASE به همراه متاداده (QoS Configured → Enabling) |
| 0x04 | Receiver Start Ready | اعلام آمادگی گیرنده (Enabling → Streaming در سمت سرور) |
| 0x05 | Disable | توقف جریان صوتی (Streaming → Disabling) |
| 0x06 | Receiver Stop Ready | اعلام توقف گیرنده |
| 0x07 | Update Metadata | تغییر متاداده در حین پخش جریان صوتی |
| 0x08 | Release | برچیدن ASE (هر وضعیتی → Releasing → Idle) |
جریان صوتی تکپخشی BAP (BAP Unicast Audio Flow)
یک دستگاه ممکن است چندین ASE با جهتهای گوناگون ارائه دهد. در سناریوی مکالمه (تلفنی)، دستگاه راه دور معمولاً دستکم دارای یک ASE از نوع Sink (دریافتکننده صدا، مانند بلندگو) و یک ASE از نوع Source (ارسالکننده صدا، مانند میکروفون) است. هر دو ASE از یک CIG مشترک و اغلب از همان CIS یکسان استفاده میکنند و از قابلیت دوطرفه جریانهای همگاه متصل (Connected Isochronous Streams یا CIS) بهره میبرند.
شاخصهای جهت در ردگیریهای btmon:
- دستور Receiver Start Ready فقط برای ASEهای Source (ASEهایی که صدا را به سمت دستگاه محلی میفرستند) ارسال میشود. سرور این دستور را صادر میکند تا نشان دهد آماده ارسال داده است.
- دستور Receiver Stop Ready نیز به همین ترتیب برای ASEهای Source اعمال میگردد.
- نقاط پایانی Sink به طور مستقیم و بدون نیاز به Receiver Start Ready از وضعیت Enabling به Streaming منتقل میشوند.
توالی راهاندازی معمول دوطرفه (دو ASE روی یک CIS):
Config Codec ASE ID=1 (Sink) → Codec Configured Config Codec ASE ID=3 (Source) → Codec Configured Config QoS ASE ID=1 → QoS Configured (CIG=X, CIS=Y) Config QoS ASE ID=3 → QoS Configured (CIG=X, CIS=Y) Enable ASE ID=1 → Enabling → Streaming (immediate) Enable ASE ID=3 → Enabling CIS Established (Success) Setup ISO Data Path Input (Host→Controller, for Sink) Setup ISO Data Path Output (Controller→Host, for Source) Receiver Start Ready ASE ID=3 → Streaming
هر دو ASE ممکن است در زمانهای متفاوتی به وضعیت Streaming برسند. ASE مربوط به Sink میتواند به محض برقراری ارتباط CIS دریافت صدا را آغاز کند، در حالی که ASE مربوط به Source منتظر دستتکانی Receiver Start Ready میماند.
نکته:
چندین ASE در هر جهت نیز معتبر و مجاز است. برای نمونه، یک هدست استریو ممکن است دو ASE از نوع Sink (کانالهای چپ و راست) و یک ASE از نوع Source (میکروفون مونو) ارائه دهد که هر کدام دارای هندل GATT اختصاصی خود برای دریافت اعلانهای وضعیت ASE هستند.
برقراری ارتباط CIS (CIS Establishment)
پس از پیکربندی کیفیت خدمات (QoS) مربوط به ASE، میزبان جریانهای همگاه متصل (Connected Isochronous Streams یا CIS) را در سطح HCI ایجاد میکند.
پارامترهای CIG (پیکربندی گروه CIS):
< HCI Command: LE Set CIG Parameters (0x08|0x0062) plen 26 #590 [hci0] 1.624003
CIG ID: 0x00
Central to Peripheral SDU Interval: 10000 us
Peripheral to Central SDU Interval: 10000 us
SCA: 0x00
Packing: Sequential (0x00)
Framing: Unframed (0x00)
Central to Peripheral Max Latency: 10 ms
Peripheral to Central Max Latency: 10 ms
Number of CIS: 1
CIS ID: 0x00
Central to Peripheral Max SDU: 120
Peripheral to Central Max SDU: 0
Central to Peripheral PHY: LE 2M PHY
Peripheral to Central PHY: LE 2M PHY
Central to Peripheral RTN: 2
Peripheral to Central RTN: 2
> HCI Event: Command Complete (0x0e) plen 8 #592 [hci0] 1.624556
LE Set CIG Parameters (0x08|0x0062) ncmd 1
Status: Success (0x00)
CIG ID: 0x00
Number of Handles: 1
Connection Handle: 2064
ایجاد CIS:
< HCI Command: LE Create CIS (0x08|0x0064) plen 9 #594 [hci0] 1.688003
Number of CIS: 1
CIS Handle: 2064
ACL Handle: 2048
> HCI Event: LE Meta Event (0x3e) plen 29 #596 [hci0] 1.756556
LE CIS Established (0x19)
Status: Success (0x00)
Connection Handle: 2064
CIG Sync Delay: 5000 us
CIS Sync Delay: 5000 us
Central to Peripheral Latency: 10000 us
Peripheral to Central Latency: 10000 us
Central to Peripheral PHY: LE 2M PHY
Peripheral to Central PHY: LE 2M PHY
NSE: 3
Central to Peripheral BN: 1
Peripheral to Central BN: 0
Central to Peripheral FT: 2
Peripheral to Central FT: 2
Max PDU C to P: 120
Max PDU P to C: 0
ISO Interval: 10.00 msec (0x0008)
توجه داشته باشید که هندل CIS (مقدار 2064) با هندل ACL (مقدار 2048) متفاوت است. بستههای داده CIS از هندل CIS استفاده میکنند.
راهاندازی مسیر داده ISO (ISO Data Path Setup):
< HCI Command: LE Setup ISO Data Path (0x08|0x006e) plen 13 #598 [hci0] 1.820003
Handle: 2064
Data Path Direction: Input (Host to Controller) (0x00)
Data Path ID: HCI (0x00)
Coding Format: LC3 (0x06)
Company ID: 0x0000
Vendor Codec ID: 0x0000
Controller Delay: 0 us
پس از این مرحله، بستههای داده ISO روی هندل CIS جریان مییابند:
< ISO Data TS: Handle 2064 flags 0x02 dlen 124 #600 [hci0] 1.884003
صدای همگانی (BIS / Auracast) (Broadcast Audio (BIS / AURACAST))
جریانهای همگاه همگانی (Broadcast Isochronous Streams) به جای CIS از گروه همگاه همگانی (Broadcast Isochronous Group یا BIG) استفاده میکنند. راهاندازی شامل تبلیغات دورهای به همراه اعلانهای BASE (نقطه پایانی منبع صوتی همگانی / Broadcast Audio Source Endpoint) است.
اعلان BASE (در دادههای تبلیغات دورهای):
> HCI Event: LE Meta Event (0x3e) plen 80 #200 [hci0] 0.500003
LE Periodic Advertising Report (0x0f)
...
Service Data: Basic Audio Announcement (0x1851)
Presentation Delay: 40000 us
Number of Subgroups: 1
Number of BIS: 2
Codec: LC3 (0x06)
Sampling Frequency: 48000 Hz
Frame Duration: 10 ms
Frame Length: 120
BIS #1
Audio Channel Allocation: Front Left
BIS #2
Audio Channel Allocation: Front Right
ایجاد BIG (سمت منبع):
< HCI Command: LE Create BIG (0x08|0x0068) plen 31 #210 [hci0] 0.600003
BIG Handle: 0x00
Advertising Handle: 0x01
Number of BIS: 2
SDU Interval: 10000 us
Max SDU: 120
Max Latency: 10 ms
RTN: 2
PHY: LE 2M PHY
Packing: Sequential (0x00)
Framing: Unframed (0x00)
Encryption: Unencrypted (0x00)
همگامسازی BIG (سمت گیرنده):
< HCI Command: LE BIG Create Sync (0x08|0x006b) plen 15 #220 [hci0] 0.700003
BIG Handle: 0x00
Sync Handle: 0x0001
Encryption: Unencrypted (0x00)
Number of BIS: 2
BIS: 0x01
BIS: 0x02
جریان گیرنده همگامسازی BIG (BIG Sync Receiver Flow)
گیرنده پیش از آنکه بتواند صدای همگانی (Broadcast Audio) را دریافت کند، باید توالی مشخصی از مراحل را تکمیل نماید. زنجیره پیشنیازهای حیاتی عبارت است از:
- 1.
- همگامسازی با تبلیغات دورهای (PA) -- گیرنده ابتدا باید رشته تبلیغات دورهای فرستنده برودکست را کشف کرده و با آن همگام شود.
- 2.
- دریافت گزارشهای PA حاوی BASE -- دادههای تبلیغات دورهای شامل ساختار BASE (نقطه پایانی منبع صوتی همگانی) است که پیکربندی کدک برودکست را توصیف میکند.
- 3.
- دریافت گزارش تبلیغاتی BIG Info -- این رویداد به گیرنده اطلاع میدهد که یک BIG در رشته تبلیغات دورهای وجود دارد و پارامترهای آن (تعداد BIS، رمزنگاری، فاصله زمانی SDU و غیره) را ارائه میدهد. این گیت و شرط حیاتی است: بدون دریافت BIG Info، گیرنده نمیتواند دستور LE BIG Create Sync را صادر کند.
- 4.
- صدور دستور LE BIG Create Sync -- با استفاده از هندل همگامسازی مرحله ۱ و پارامترهای مرحله ۳.
- 5.
- دریافت رویداد BIG Sync Established -- کنترلکننده همگامسازی را به همراه هندلهای اتصال BIS تأیید میکند.
- 6.
- راهاندازی مسیر داده ISO (Setup ISO Data Path) -- پیکربندی مسیر داده برای هر یک از BISها.
- 7.
- جریان یافتن دادههای ISO -- بستههای صوتی همگانی دریافت میشوند.
اگر هر یک از این مراحل با شکست مواجه شود یا وجود نداشته باشد، مراحل بعدی نمیتوانند ادامه یابند. رایجترین الگوی شکست این است که BIG Info هرگز دریافت نمیشود (برای مثال، دادههای تبلیغات دورهای شامل BIG نیست، یا همگامسازی PA پیش از رسیدن BIG Info قطع شده است)، که به این معنی است که دستور LE BIG Create Sync هرگز ارسال نخواهد شد.
بدون PAST (همگامسازی مستقیم PA) (Without PAST (Direct PA Sync))
هنگامی که گیرنده بهطور مستقیم (بدون کمک دستیار برودکست / Broadcast Assistant) برای تبلیغات دورهای اسکن کرده و با آن همگام میشود:
مرحله ۱ -- ایجاد همگامسازی PA (Create PA sync):
< HCI Command: LE Periodic Advertising Create Sync (0x08|0x0044) plen 14 #100 [hci0] 0.100003
Options: 0x0000
SID: 0x01
Adv Address Type: Public (0x00)
Adv Address: XX:XX:XX:XX:XX:XX
Skip: 0x0000
Sync Timeout: 2000 msec (0x00c8)
Sync CTE Type: 0x0000
مرحله ۲ -- برقراری همگامسازی PA (تخصیص هندل همگامسازی):
> HCI Event: LE Meta Event (0x3e) plen 16 #105 [hci0] 0.150003
LE Periodic Advertising Sync Established (0x0e)
Status: Success (0x00)
Sync Handle: 0x0001
Advertising SID: 0x01
Advertiser Address Type: Public (0x00)
Advertiser Address: XX:XX:XX:XX:XX:XX
Advertiser PHY: LE 2M PHY (0x02)
Periodic Advertising Interval: 10.000 msec (0x0008)
Advertiser Clock Accuracy: 0x05
مرحله ۳ -- گزارشهای PA (شامل دادههای BASE):
> HCI Event: LE Meta Event (0x3e) plen 80 #110 [hci0] 0.200003
LE Periodic Advertising Report (0x0f)
Sync Handle: 0x0001
...
Service Data: Basic Audio Announcement (0x1851)
مرحله ۴ -- گزارش تبلیغاتی BIG Info (گیت حیاتی):
> HCI Event: LE Meta Event (0x3e) plen 24 #120 [hci0] 0.300003
LE BIG Info Advertising Report (0x22)
Sync Handle: 0x0001
Number BIS: 2
NSE: 4
ISO Interval: 10.000 msec (0x0008)
BN: 2
PTO: 1
IRC: 2
Maximum PDU: 120
SDU Interval: 10000 us
Maximum SDU: 120
PHY: LE 2M PHY (0x02)
Framing: Unframed (0x00)
Encryption: 0x00
این رویداد هر بار که کنترلکننده یک بسته تبلیغات دورهای حاوی BIG Info دریافت کند، تولید میشود. این رویداد تمامی پارامترهای مورد نیاز گیرنده را برای تصمیمگیری در مورد همگامسازی با BIG فراهم میکند. فیلدهای کلیدی:
- Number BIS -- تعداد جریانهای BIS موجود.
- SDU Interval و Maximum SDU -- زمانبندی و اندازه فریم صوتی.
- Encryption -- مشخص میکند که آیا کد برودکست (Broadcast Code) لازم است (0x01) یا خیر (0x00). در صورت رمزنگاری، گیرنده باید کد برودکست صحیح را در LE BIG Create Sync ارائه دهد.
- Sync Handle -- باید با یک همگامسازی PA فعال فعلی مطابقت داشته باشد.
مرحله ۵ -- دستور BIG Create Sync (با استفاده از هندل همگامسازی + BIG Info):
< HCI Command: LE BIG Create Sync (0x08|0x006b) plen 15 #130 [hci0] 0.400003
BIG Handle: 0x00
BIG Sync Handle: 0x0001
Encryption: Unencrypted (0x00)
Broadcast Code: 00000000000000000000000000000000
Maximum Number Subevents: 0x00
Timeout: 2000 ms (0x00c8)
Number of BIS: 2
BIS: 0x01
BIS: 0x02
مرحله ۶ -- برقراری همگامسازی BIG (BIG Sync Established):
> HCI Event: LE Meta Event (0x3e) plen 20 #135 [hci0] 0.450003
LE BIG Sync Established (0x1d)
Status: Success (0x00)
BIG Handle: 0x00
Transport Latency: 10000 us
NSE: 4
BN: 2
PTO: 1
IRC: 2
Maximum PDU: 120
ISO Interval: 10.000 msec (0x0008)
Connection Handle: 0x0010
Connection Handle: 0x0011
در صورت موفقیت، کنترلکننده هندلهای اتصال BIS را اختصاص میدهد (0x0010 و 0x0011 در بالا). یک وضعیت (Status) غیرصفر نشاندهنده شکست است -- خطاهای رایج:
- 0x3e (برقراری ارتباط با شکست مواجه شد / Connection Failed to be Established) -- پارامترهای BIG مطابقت ندارند یا BIG دیگر وجود ندارد.
- 0x3f (رسیدن به حد مجاز / Limit Reached) -- منابع کنترلکننده به پایان رسیده است.
مرحله ۷ -- راهاندازی مسیر داده ISO (برای هر BIS):
< HCI Command: LE Setup ISO Data Path (0x08|0x006e) plen 13 #140 [hci0] 0.500003
Connection Handle: 0x0010
Data Path Direction: Output (Controller to Host) (0x01)
Data Path ID: HCI (0x00)
< HCI Command: LE Setup ISO Data Path (0x08|0x006e) plen 13 #145 [hci0] 0.550003
Connection Handle: 0x0011
Data Path Direction: Output (Controller to Host) (0x01)
Data Path ID: HCI (0x00)
مرحله ۸ -- جریان یافتن دادههای ISO روی هندلهای BIS:
> ISO Data: Handle 0x0010 flags 0x02 dlen 124 #150 [hci0] 0.600003 > ISO Data: Handle 0x0011 flags 0x02 dlen 124 #151 [hci0] 0.600003
همراه با PAST (انتقال همگامسازی تبلیغات دورهای) (With PAST (Periodic Advertising Sync Transfer))
هنگامی که یک دستیار برودکست (مانند یک گوشی هوشمند) به یک نماینده اسکن (مانند سمعک) کمک میکند تا با یک پخش همگانی همگام شود، میتواند همگامسازی PA را از طریق PAST بر روی یک اتصال ACL موجود منتقل کند. این کار از اسکن و همگامسازی مستقیم نماینده با رشته PA جلوگیری میکند.
پروتکل BASS (سرویس اسکن صوتی همگانی / Broadcast Audio Scan Service) این فرایند را هماهنگ میکند:
- 1.
- دستیار یک عملیات Add Source را روی نقطه کنترل BASS نماینده مینویسد که در آن PA Sync روی 0x01 (همگامسازی از طریق PAST) تنظیم شده است.
- 2.
- نماینده با تنظیم پارامترهای PAST، خود را برای دریافت انتقال آماده میکند.
- 3.
- دستیار همگامسازی PA خود را به نماینده منتقل میکند.
- 4.
- نماینده رویداد PAST را به همراه یک هندل همگامسازی دریافت میکند.
- 5.
- از این نقطه به بعد، جریان مانند حالت بدون PAST ادامه مییابد (گزارشهای PA → رویداد BIG Info → دستور BIG Create Sync → و غیره).
عملیات BASS Add Source (نوشتن دستیار در نماینده، مشاهدهشده در ATT):
< ACL Data TX: Handle 64 flags 0x00 dlen 27 #300 [hci0] 1.000003
ATT: Write Command (0x52) len 22
Handle: 0x0025
Data: 04...
Opcode: Add Source (0x04)
Advertiser Address Type: Public (0x00)
Advertiser Address: XX:XX:XX:XX:XX:XX
Advertising SID: 0x01
PA Sync: Synchronize to PA - PAST (0x01)
PA Interval: 0x0008
Number of Subgroups: 1
BIS Sync: 0x00000003
Metadata Length: 0
مقادیر PA Sync در عملیات Add Source:
- 0x00 -- عدم همگامسازی با PA
- 0x01 -- همگامسازی با PA، قابلیت PAST موجود است
- 0x02 -- همگامسازی با PA، قابلیت PAST موجود نیست (نماینده باید مستقیماً اسکن و همگامسازی کند)
پارامترهای PAST (PAST Parameters) (نماینده برای دریافت انتقال آماده میشود):
< HCI Command: LE Periodic Advertising Sync Transfer Parameters (0x08|0x005c) plen 8 #310 [hci0] 1.100003
Connection handle: 64
Mode: Enabled with report events enabled (0x02)
Skip: 0x00
Sync timeout: 2000 msec (0x00c8)
Sync CTE Type: 0x0000
انتقال PAST (PAST Transfer) (دستیار همگامسازی PA خود را ارسال میکند):
< HCI Command: LE Periodic Advertising Sync Transfer (0x08|0x005a) plen 6 #320 [hci0] 1.200003
Connection handle: 64
Service data: 0x0001
Sync handle: 1
دریافت PAST (PAST Received) (نماینده هندل همگامسازی را دریافت میکند):
> HCI Event: LE Meta Event (0x3e) plen 19 #325 [hci0] 1.250003
LE Periodic Advertising Sync Transfer Received (0x18)
Status: Success (0x00)
Handle: 64
Connection handle: 64
Service data: 0x0001
Sync handle: 1
SID: 0x01
Address type: Public (0x00)
Address: XX:XX:XX:XX:XX:XX
PHY: LE 2M PHY (0x02)
Periodic advertising Interval: 10.000
Clock Accuracy: 0x05
در صورت موفقیت، نماینده اکنون دارای یک همگامسازی PA است (Sync handle: 1) و دریافت گزارشهای PA و رویدادهای BIG Info را آغاز خواهد کرد و جریان را از مرحله ۳ حالت بدون PAST در بالا ادامه میدهد.
نکته:
برچیدن همگامسازی BIG (BIG Sync Teardown)
برچیدن به ابتکار گیرنده -- گیرنده همگامسازی BIG خود را خاتمه میدهد:
< HCI Command: LE BIG Terminate Sync (0x08|0x006c) plen 1 #500 [hci0] 5.000003
BIG Handle: 0x00
> HCI Event: Command Complete (0x0e) plen 5 #501 [hci0] 5.001003
LE BIG Terminate Sync (0x08|0x006c) ncmd 1
Status: Success (0x00)
BIG Handle: 0x00
برچیدن به ابتکار فرستنده برودکست -- فرستنده BIG خود را خاتمه میدهد و گیرنده رویداد BIG Sync Lost را دریافت میکند:
> HCI Event: LE Meta Event (0x3e) plen 2 #510 [hci0] 6.000003
LE BIG Sync Lost (0x1e)
BIG Handle: 0x00
Reason: Connection Terminated By Local Host (0x16)
فیلد Reason دلیل قطع همگامسازی را نشان میدهد:
- 0x08 (اتمام مهلت اتصال / Connection Timeout) -- بستههای BIG در مدت مهلت همگامسازی دریافت نشدند.
- 0x13 (اتصال توسط کاربر راه دور خاتمه یافت / Remote User Terminated Connection) -- فرستنده برودکست عمداً BIG را متوقف کرد.
- 0x16 (اتصال توسط میزبان محلی خاتمه یافت / Connection Terminated By Local Host) -- کنترلکننده محلی اتصال را خاتمه داد.
- 0x3e (برقراری ارتباط با شکست مواجه شد / Connection Failed to be Established) -- در ابتدا امکان برقراری همگامسازی وجود نداشت.
خاتمه BIG در سمت منبع (Source-side BIG termination) (فرستنده برودکست را برمیچیند):
< HCI Command: LE Terminate BIG (0x08|0x006a) plen 2 #520 [hci0] 7.000003
BIG Handle: 0x00
Reason: Connection Terminated By Local Host (0x16)
> HCI Event: LE Meta Event (0x3e) plen 2 #521 [hci0] 7.001003
LE BIG Terminate (0x1c)
BIG Handle: 0x00
Reason: Connection Terminated By Local Host (0x16)
عیبیابی شکست همگامسازی BIG (BIG Sync Failure Diagnosis)
هنگام تحلیل ردگیری در مواردی که همگامسازی BIG شکست میخورد، موارد زیر را به ترتیب بررسی کنید:
- 1.
- آیا همگامسازی PA برقرار شده است؟ -- به دنبال رویداد LE Periodic Advertising Sync Established با وضعیت Status: Success بگردید. اگر وجود ندارد، گیرنده هرگز با رشته PA همگام نشده است.
- 2.
- آیا گزارشهای PA دریافت میشوند؟ -- به دنبال رویدادهای LE Periodic Advertising Report بگردید. اگر پس از همگامسازی PA غایب باشند، ممکن است رشته PA قطع شده باشد.
- 3.
- آیا BIG Info دریافت شده است؟ -- به دنبال LE BIG Info Advertising Report بگردید. اگر این رویداد هرگز ظاهر نشود، BIG روی این رشته PA وجود ندارد، یا فرستنده برودکست هنوز آن را راهاندازی نکرده است. بدون BIG Info، دستور LE BIG Create Sync ارسال نمیشود.
- 4.
- آیا BIG Create Sync ارسال شده است؟ -- اگر BIG Info دریافت شده اما LE BIG Create Sync هرگز ارسال نشده است، منطق سمت میزبان در واکنش به BIG Info عمل نکرده است (مثلاً ناسازگاری کدک، عدم تطابق رمزنگاری یا اشکال در سطح برنامه).
- 5.
- آیا BIG Sync Established با موفقیت انجام شد؟ -- فیلد Status را بررسی کنید. یک وضعیت غیرصفر به این معنی است که کنترلکننده نتوانسته با BIG همگام شود.
- 6.
- آیا مسیر داده ISO راهاندازی شده است؟ -- به دنبال LE Setup ISO Data Path برای هر یک از هندلهای BIS برگرفته از BIG Sync Established بگردید.
- 7.
- آیا دادههای ISO جریان دارند؟ -- به دنبال بستههای ISO Data روی هندلهای BIS بگردید.
خودکارسازی تحلیل LE Audio (Automating LE Audio Analysis)
شناسایی فعالیت LE Audio:
grep -n "ASE Control Point\|ASE ID\|State:.*Codec Configured\|State:.*QoS Configured\|State:.*Enabling\|State:.*Streaming\|State:.*Releasing" output.txt
ردگیری تغییرات وضعیت ASE برای یک ASE مشخص:
grep -n "ASE ID:" output.txt
سپس خط State: پس از هر تطابق ASE ID را بررسی کنید.
بررسی پیکربندی کدک:
grep -n "Codec: LC3\|Sampling Frequency:\|Frame Duration:\|Frame Length:\|Audio Channel" output.txt
بررسی و اعتبارسنجی برقراری CIS:
grep -n "Set CIG Parameters\|Create CIS\|CIS Established\|Setup ISO Data Path" output.txt
تشخیص شکستهای CIS -- بررسی فیلد Status پس از CIS Established:
grep -n "CIS Established" output.txt
سپس خط بعدی را برای یافتن Status: بررسی کنید.
تشخیص صدای همگانی (برودکست):
grep -n "Basic Audio Announcement\|Create BIG\|BIG Complete\|BIG Create Sync\|BIG Sync\|BIG Info\|BIG Terminate\|BIG Sync Lost" output.txt
ردگیری جریان گیرنده همگامسازی BIG -- اعتبارسنجی تکتک مراحل پیشنیاز:
grep -n "Periodic Advertising Create Sync\|Periodic Advertising Sync Established\|BIG Info Advertising Report\|BIG Create Sync\|BIG Sync Established\|BIG Sync Lost\|BIG Terminate" output.txt
تشخیص همگامسازی مبتنی بر PAST -- بررسی انتقال همگامسازی تبلیغات دورهای:
grep -n "Sync Transfer Parameters\|Sync Transfer (0x08\|PAST Received\|PA Sync:.*PAST\|Add Source" output.txt
بررسی دریافت BIG Info -- گیت حیاتی برای همگامسازی BIG. در صورت عدم وجود این رویداد، گیرنده هیچ BIG برای همگامسازی با آن ندارد:
grep -n "BIG Info Advertising Report" output.txt
الگوی کامل عیبیابی LE Audio:
جریان تکپخشی (CIS):
- 1.
- یافتن خواندنهای PACS -- تأیید سازگاری کدک میان دستگاهها
- 2.
- یافتن نوشتنهای نقطه کنترل ASE -- ردگیری توالی Config Codec → Config QoS → Enable
- 3.
- یافتن اعلانهای وضعیت ASE -- تأیید موفقیتآمیز بودن هر انتقال وضعیت
- 4.
- یافتن پارامترهای CIG و ایجاد CIS -- تأیید راهاندازی در سطح HCI
- 5.
- یافتن CIS Established -- بررسی وضعیت Status برای موفقیت
- 6.
- یافتن Setup ISO Data Path -- تأیید پیکربندی مسیر داده
- 7.
- یافتن بستههای داده ISO -- تأیید جریان داشتن صدا
- 8.
- در صورت شکست، بررسی پاسخهای اعلان نقطه کنترل ASE برای یافتن کدهای خطا (فیلدهای Response Code و Response Reason)
جریان گیرنده صدای همگانی (BIG):
- 1.
- یافتن Periodic Advertising Create Sync یا PAST Received -- همگامسازی PA چگونه آغاز شد؟
- 2.
- یافتن Periodic Advertising Sync Established یا PAST Received با وضعیت Status: Success -- آیا PA همگام شده است؟
- 3.
- یافتن Periodic Advertising Report با Basic Audio Announcement -- آیا دادههای BASE دریافت میشوند؟
- 4.
- یافتن BIG Info Advertising Report -- بسیار حیاتی: آیا BIG وجود دارد؟ در صورت عدم وجود، همگامسازی با BIG امکانپذیر نیست.
- 5.
- یافتن BIG Create Sync -- آیا میزبان درخواست همگامسازی با BIG را ارسال کرده است؟
- 6.
- یافتن BIG Sync Established -- بررسی Status برای موفقیت.
- 7.
- یافتن Setup ISO Data Path برای هر یک از هندلهای BIS.
- 8.
- یافتن ISO Data روی هندلهای BIS -- تأیید جریان داشتن صدا.
- 9.
- در صورت شکست، بررسی BIG Sync Lost و بررسی فیلد Reason.
جریان پروتکل سنجش کانال (CHANNEL SOUNDING PROTOCOL FLOW)
سنجش کانال (Channel Sounding یا CS) اندازهگیری دقیق فاصله بین دو دستگاه بلوتوث کممصرف (Bluetooth LE) را امکانپذیر میسازد. این سازوکار از دستورات و رویدادهای اختصاصی HCI برای پیکربندی و اجرای رویههای اندازهگیری بهره میبرد که تنها (tones) و بستههای زمانبندی را روی کانالهای چندگانه مبادله میکنند. ابزار btmon تمام عملیات CS، از جمله دادههای نتایج در سطح گام (step-level) را بهطور کامل رمزگشایی و تحلیل میکند.
سنجش کانال (CS) از دو نقش استفاده میکند: آغازگر (Initiator) بستههای CS را ابتدا در هر گام ارسال میکند، و بازتابدهنده (Reflector) پاسخ میدهد. هر دو دستگاه باید از CS پشتیبانی کنند (بیتهای ویژگی ۴۶ تا ۴۸ در مجموعه ویژگیهای LE).
کشف قابلیتها (Capability Discovery)
پیش از هرگونه فعالیت سنجش کانال (CS)، هر دو دستگاه باید از قابلیتهای CS یکدیگر آگاه شوند. قابلیتهای کنترلکننده (Controller) محلی یک بار خوانده میشود و قابلیتهای دستگاه راه دور از طریق امواج رادیویی (over the air) دریافت میگردد.
خواندن قابلیتهای محلی CS:
< HCI Command: LE CS Read Local Supported Capabilities (0x08|0x0089) plen 0 #100 [hci0]
> HCI Event: Command Complete (0x0e) plen 42 #101 [hci0]
LE CS Read Local Supported Capabilities (0x08|0x0089) ncmd 1
Status: Success (0x00)
Num Config Supported: 4
Max Consecutive Procedures Supported: 255
Num Antennas Supported: 2
Max Antenna Paths Supported: 4
Roles Supported: 0x03
Initiator
Reflector
Modes Supported: 0x03
RTT Capability: 0x03
RTT AA Only N: 10
RTT Sounding N: 10
RTT Random Payload N: 10
CS Sync PHYs Supported: 0x02
LE 2M
T_IP1 Times Supported: 0x0005
10 us
30 us
T_IP2 Times Supported: 0x0005
10 us
30 us
T_FCS Times Supported: 0x0009
15 us
50 us
T_PM Times Supported: 0x0003
10 us
20 us
فیلدهای کلیدی قابلیتها:
- Roles Supported -- ماسک بیت: بیت 0 = آغازگر (Initiator)، بیت 1 = بازتابدهنده (Reflector). یک دستگاه باید حداقل از یک نقش پشتیبانی کند.
- Modes Supported -- ماسک بیت حالتهای اندازهگیری CS که کنترلکننده میتواند انجام دهد (حالت ۱ = RTT، حالت ۲ = تن PBR، حالت ۳ = هر دو).
- CS Sync PHYs -- لایههای فیزیکی موجود برای تبادل همگامسازی CS. گزینه LE 2M رایجترین حالت است.
- Num Antennas / Max Antenna Paths -- قابلیت فاصلهسنجی مبتنی بر فاز (PBR) چندآنتنی را تعیین میکند.
- T_IP / T_FCS / T_PM times -- پارامترهای زمانبندی پشتیبانیشده توسط کنترلکننده برای فواصل بینگامی و مدتزمانهای تن.
خواندن قابلیتهای CS راه دور (از طریق امواج رادیویی به واسطه LL):
< HCI Command: LE CS Read Remote Supported Capabilities (0x08|0x008a) plen 2 #110 [hci0]
Handle: 2048
> HCI Event: Command Status (0x0f) plen 4 #111 [hci0]
LE CS Read Remote Supported Capabilities (0x08|0x008a) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 42 #115 [hci0]
LE CS Read Remote Supported Capabilities Complete (0x2c)
Status: Success (0x00)
Handle: 2048
Num Config Supported: 4
Max Consecutive Procedures Supported: 128
Num Antennas Supported: 1
Max Antenna Paths Supported: 1
Roles Supported: 0x03
Initiator
Reflector
Modes Supported: 0x03
...
این یک دستور ناهمگام (asynchronous) است -- کنترلکننده وضعیت دستور (Command Status) را بلافاصله ارسال میکند، سپس رویداد تکمیل پس از تبادل LL دریافت میشود. اگر این دستور با وضعیتی غیرصفر با شکست مواجه شود، ممکن است دستگاه راه دور از CS پشتیبانی نکند یا اتصال قطع شده باشد.
قابلیتهای ذخیرهشده در حافظهپنهان (cached) را میتوان مستقیماً بهجای خواندن از طریق امواج، با استفاده از LE CS Write Cached Remote Supported Capabilities نوشت.
فعالسازی امنیت (Security Enablement)
امنیت CS باید پیش از ایجاد پیکربندیها روی اتصال فعال شود. این دستور رویه شروع امنیت CS را از طریق LL برای تبادل مقادیر یکبارمصرف (nonces) انجام میدهد:
< HCI Command: LE CS Security Enable (0x08|0x008c) plen 2 #120 [hci0]
Handle: 2048
> HCI Event: Command Status (0x0f) plen 4 #121 [hci0]
LE CS Security Enable (0x08|0x008c) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 3 #125 [hci0]
LE CS Security Enable Complete (0x2e)
Status: Success (0x00)
Handle: 2048
دستور فعالسازی امنیت (Security Enable) باید پیش از دستورات پیکربندی یا رویه با موفقیت تکمیل شود. اگر این دستور با شکست مواجه شود، ممکن است اتصال فاقد رمزنگاری باشد یا دستگاه راه دور از امنیت CS پشتیبانی نکند.
تنظیمات پیشفرض (Default Settings)
تنظیمات پیشفرض مشخص میکنند که دستگاه محلی مایل به پذیرش چه نقشهایی است و ترجیحات آنتن/توان را برای این اتصال پیکربندی میکنند:
< HCI Command: LE CS Set Default Settings (0x08|0x008d) plen 5 #130 [hci0]
Handle: 2048
Role Enable: 0x03
Initiator
Reflector
CS Sync Antenna Selection: 0x01
Max TX Power: 20
> HCI Event: Command Complete (0x0e) plen 5 #131 [hci0]
LE CS Set Default Settings (0x08|0x008d) ncmd 1
Status: Success (0x00)
Handle: 2048
- Role Enable -- ماسک بیت نقشهایی که دستگاه مایل به انجام آنها است. هر دو طرف معمولاً هر دو نقش را برای انعطافپذیری فعال میکنند.
- CS Sync Antenna Selection -- آنتن ترجیحی برای تبادل همگامسازی CS.
- Max TX Power -- کران بالای توان ارسال برای رویههای CS (برحسب dBm، علامتدار).
تبادل جدول FAE (FAE Table Exchange)
جدول خطای تحریک فرکانس (FAE مخفف Frequency Actuation Error) حاوی دادههای کالیبراسیون به ازای هر کانال است که دقت اندازهگیری فاصله را بهبود میبخشد. همانند قابلیتها، این جدول را میتوان از دستگاه راه دور خواند یا از حافظهپنهان نوشت.
خواندن جدول FAE راه دور:
< HCI Command: LE CS Read Remote FAE Table (0x08|0x008e) plen 2 #135 [hci0]
Handle: 2048
> HCI Event: Command Status (0x0f) plen 4 #136 [hci0]
LE CS Read Remote FAE Table (0x08|0x008e) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 75 #140 [hci0]
LE CS Read Remote FAE Table Complete (0x2d)
Status: Success (0x00)
Handle: 2048
جدول FAE برابر ۷۲ بایت است (یک بایت به ازای هر کانال). مقادیر، آفستهای علامتدار در واحدهای 0.5 ppm هستند. مقدار 0x7f به این معناست که کانال بدون استفاده بوده یا اندازهگیری نشده است.
پیکربندی سنجش کانال (CS Configuration)
پیکربندی CS پارامترهای اندازهگیری را تعیین میکند: حالت، نقش، نقشه کانال و تعداد گامها. حداکثر ۴ پیکربندی میتوانند بهطور همزمان در هر اتصال وجود داشته باشند (config_id بین 0 تا 3).
ایجاد یک پیکربندی CS:
< HCI Command: LE CS Create Config (0x08|0x0090) plen 20 #150 [hci0]
Handle: 2048
Config ID: 0
Create Context: 0x00
Main Mode Type: 0x01
Sub Mode Type: 0xff
Min Main Mode Steps: 2
Max Main Mode Steps: 5
Main Mode Repetition: 0
Mode 0 Steps: 3
Role: Initiator (0x00)
RTT Type: 0x01
CS Sync PHY: LE 2M (0x01)
Channel Map: ffffffffff7f0000000000000000
Channel Map Repetition: 1
Channel Selection Type: 0x00
Ch3c Shape: 0x00
Ch3c Jump: 0x00
> HCI Event: Command Status (0x0f) plen 4 #151 [hci0]
LE CS Create Config (0x08|0x0090) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 30 #155 [hci0]
LE CS Config Complete (0x2f)
Status: Success (0x00)
Handle: 2048
Config ID: 0
Action: 0x00
Main Mode Type: 0x01
Sub Mode Type: 0xff
Min Main Mode Steps: 2
Max Main Mode Steps: 5
Main Mode Repetition: 0
Mode 0 Steps: 3
Role: Initiator (0x00)
RTT Type: 0x01
CS Sync PHY: LE 2M (0x01)
Channel Map: ffffffffff7f0000000000000000
Channel Map Repetition: 1
Channel Selection Type: 0x00
Ch3c Shape: 0x00
Ch3c Jump: 0x00
T_IP1 Time: 30 us
T_IP2 Time: 30 us
T_FCS Time: 50 us
T_PM Time: 10 us
فیلدهای کلیدی پیکربندی:
- Main Mode Type -- حالت اصلی اندازهگیری CS: 0x01 = حالت ۱ (فقط RTT)، 0x02 = حالت ۲ (فقط تن/PBR)، 0x03 = حالت ۳ (ترکیب RTT + PBR).
- Sub Mode Type -- حالت ثانویه که بهصورت درهمتنیده با حالت اصلی اجرا میشود. 0xff = بدون حالت فرعی.
- Mode 0 Steps -- تعداد گامهای کالیبراسیون فرکانس (همگامسازی) در هر زیررویداد. حالت ۰ همیشه برای جبران آفست فرکانس حضور دارد.
- Main/Min/Max Mode Steps -- کنترل میکند که چه تعداد گام اندازهگیری در هر زیررویداد انجام شود.
- Role -- 0x00 = آغازگر (Initiator)، 0x01 = بازتابدهنده (Reflector). این نقش دستگاه محلی در این پیکربندی است.
- RTT Type -- گونه اندازهگیری زمان رفت و برگشت (فقط AA، توالی سنجش، توالی تصادفی).
- Channel Map -- ماسک بیت ۱۰ بایتی کانالهای مجاز برای CS. باید حداقل ۱۵ کانال فعال داشته باشد.
- T_IP1/T_IP2/T_FCS/T_PM -- پارامترهای زمانبندی انتخابشده توسط کنترلکننده بر اساس اشتراک قابلیتهای هر دو دستگاه. در رویداد Config Complete گزارش میشوند.
رویداد Config Complete پارامترهای توافقشده را تایید میکند. کنترلکننده ممکن است مقادیر زمانبندی را بر اساس قابلیتهای هر دو دستگاه تنظیم کند.
حذف یک پیکربندی CS:
< HCI Command: LE CS Remove Config (0x08|0x0091) plen 3 #160 [hci0]
Handle: 2048
Config ID: 0
> HCI Event: Command Status (0x0f) plen 4 #161 [hci0]
LE CS Remove Config (0x08|0x0091) ncmd 1
Status: Success (0x00)
پارامترهای رویه (Procedure Parameters)
پیش از فعالسازی یک رویه، پارامترهای زمانبندی و آنتن آن پیکربندی میشوند:
< HCI Command: LE CS Set Procedure Parameters (0x08|0x0093) plen 16 #170 [hci0]
Handle: 2048
Config ID: 0
Max Procedure Len: 200
Min Procedure Interval: 10
Max Procedure Interval: 20
Max Procedure Count: 0
Min Subevent Len: 5000 us
Max Subevent Len: 10000 us
Tone Antenna Config Selection: 0x01
PHY: LE 2M (0x02)
TX Power Delta: 0
Preferred Peer Antenna: 0x01
SNR Control Initiator: 0x00
SNR Control Reflector: 0x00
> HCI Event: Command Complete (0x0e) plen 5 #171 [hci0]
LE CS Set Procedure Parameters (0x08|0x0093) ncmd 1
Status: Success (0x00)
Handle: 2048
- Max Procedure Len -- حداکثر مدتزمان یک رویه واحد CS در واحدهای 0.625 میلیثانیه.
- Procedure Interval -- فاصله زمانی بین رویههای متوالی (برحسب رویدادهای اتصال).
- Max Procedure Count -- مقدار 0 به معنای تکرار نامحدود تا زمان غیرفعالسازی صریح است.
- Subevent Len -- حدود مدتزمان هر زیررویداد در یک رویه (برحسب میکروثانیه، ۲۴ بیتی).
- Tone Antenna Config Selection -- انتخاب الگوی آنتن برای تبادل تن.
- SNR Control -- الزامات نسبت سیگنال به نویز (SNR) برای آغازگر و بازتابدهنده.
اجرای رویه (Procedure Execution)
هنگامی که پیکربندی و پارامترها تعیین شدند، رویه CS با دستورات فعالسازی/غیرفعالسازی شروع و متوقف میشود.
فعالسازی یک رویه CS:
< HCI Command: LE CS Procedure Enable (0x08|0x0094) plen 4 #180 [hci0]
Handle: 2048
Config ID: 0
Enable: 0x01
> HCI Event: Command Status (0x0f) plen 4 #181 [hci0]
LE CS Procedure Enable (0x08|0x0094) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 20 #185 [hci0]
LE CS Procedure Enable Complete (0x30)
Status: Success (0x00)
Handle: 2048
Config ID: 0
State: 0x01
Tone Antenna Config Selection: 0x01
Selected TX Power: 12
Subevent Len: 5000 us
Subevents Per Event: 2
Subevent Interval: 3750
Event Interval: 10
Procedure Interval: 10
Procedure Count: 100
Max Procedure Len: 200
رویداد Procedure Enable Complete پارامترهای زمانبندی واقعی انتخابشده توسط کنترلکننده را تایید میکند. فیلدهای مهم:
- State -- 0x01 = رویه فعال است، 0x00 = غیرفعال است.
- Subevents Per Event -- تعداد زیررویدادهایی که در هر رویداد اتصال جای میگیرند.
- Procedure Count -- تعداد واقعی رویههایی که اجرا خواهند شد (ممکن است با حداکثر درخواستی تفاوت داشته باشد).
غیرفعالسازی یک رویه CS:
< HCI Command: LE CS Procedure Enable (0x08|0x0094) plen 4 #300 [hci0]
Handle: 2048
Config ID: 0
Enable: 0x00
> HCI Event: Command Status (0x0f) plen 4 #301 [hci0]
LE CS Procedure Enable (0x08|0x0094) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 20 #305 [hci0]
LE CS Procedure Enable Complete (0x30)
Status: Success (0x00)
Handle: 2048
Config ID: 0
State: 0x00
...
دستهبندی کانال (Channel Classification)
میزبان میتواند با علامتگذاری کانالهای نویزی بهعنوان غیرقابل استفاده، کانالهای مورد استفاده CS را محدود سازد:
< HCI Command: LE CS Set Channel Classification (0x08|0x0092) plen 10 #145 [hci0]
Channel Map: ffffffffff7f0000000000
> HCI Event: Command Complete (0x0e) plen 1 #146 [hci0]
LE CS Set Channel Classification (0x08|0x0092) ncmd 1
Status: Success (0x00)
نقشه کانال یک ماسک بیت ۱۰ بایتی (۸۰ بیتی) است. مقدار بیت N = 1 به این معناست که کانال N برای CS در دسترس است. حداقل ۱۵ کانال باید فعال باقی بمانند در غیر این صورت رویه لغو خواهد شد.
برنامهریزی زمانی و زیررویدادها (Schedulability and Subevents)
در حین اجرای یک رویه CS، کنترلکننده نتایج اندازهگیری را از طریق رویدادهای نتیجه زیررویداد (subevent result events) گزارش میدهد. هر زیررویداد شامل چندین گام است و هر گام حاوی دادههای اندازهگیری ویژه آن حالت است.
نتیجه زیررویداد (Subevent Result):
> HCI Event: LE Meta Event (0x3e) plen 50 #200 [hci0]
LE CS Subevent Result (0x31)
Handle: 2048
Config ID: 0
Start ACL Conn Event Counter: 1200
Procedure Counter: 0
Frequency Compensation: 0x0000
Reference Power Level: -20
Procedure Done Status: Partial results (0x01)
Subevent Done Status: All results complete (0x00)
Abort Reason: 0x00
Num Antenna Paths: 1
Num Steps Reported: 8
Step Data:
Mode: 0 Channel: 10 Length: 5
Packet Quality: 0x00
Packet RSSI: -45
Packet Antenna: 0
Measured Freq Offset: 150
Mode: 1 Channel: 20 Length: 6
Packet Quality: 0x00
Packet NADM: Attack is extremely unlikely (0x00)
Packet RSSI: -42
ToA/ToD: 1234
Packet Antenna: 0
Mode: 2 Channel: 30 Length: 5
Antenna Permutation Index: 0
PCT[0]: I=1024, Q=-512
Tone Quality: High (0x00)
...
هنگامی که دادهها بزرگ باشند، رویدادهای نتیجه میتوانند میان چندین رویداد تقسیم شوند:
ادامه نتیجه زیررویداد (Subevent Result Continue) (قطعه ادامه):
> HCI Event: LE Meta Event (0x3e) plen 40 #202 [hci0]
LE CS Subevent Result Continue (0x32)
Handle: 2048
Config ID: 0
Procedure Done Status: Partial results (0x01)
Subevent Done Status: All results complete (0x00)
Abort Reason: 0x00
Num Antenna Paths: 1
Num Steps Reported: 4
Step Data:
...
حالتهای گام سنجش کانال (CS Step Modes)
هر زیررویداد CS شامل گامهایی است که روی کانالهای مختلف اجرا میشوند. هر گام در یکی از چهار حالت عمل میکند:
حالت ۰ -- کالیبراسیون فرکانس (همگامسازی CS)
گامهای حالت ۰ همیشه در ابتدای هر زیررویداد حضور دارند. آنها یک توالی همگامسازی CS مشخص را برای کالیبراسیون آفستهای فرکانس میان دو دستگاه مبادله میکنند.
فیلدهای گزارششده:
- Packet Quality -- مقدار 0x00 = نشانی دسترسی CS تطبیق یافت، 0x01 = خطاهای بیت شناسایی شد، 0x02 = یافت نشد.
- Packet RSSI -- قدرت سیگنال دریافتی (علامتدار، dBm).
- Packet Antenna -- اندیس آنتن استفادهشده.
- Measured Freq Offset -- آفست فرکانس در واحدهای 0.01 ppm (مقدار ۱۵ بیتی). تنها در صورتی حضور دارد که طول داده ۵ باشد.
حالت ۱ -- زمان رفت و برگشت (RTT)
حالت ۱ زمان رسیدن (ToA) و زمان ارسال (ToD) را برای محاسبه تاخیر رفت و برگشت جهت تخمین فاصله اندازهگیری میکند.
فیلدهای گزارششده:
- Packet Quality -- مشابه حالت ۰.
- Packet NADM -- معیار نرمالشده آشکارساز حمله (Normalized Attack Detector Metric)، احتمال دستکاری در اندازهگیری RTT را نشان میدهد:
- 0x00 = حمله بهشدت غیرمحتمل است
- 0x01 = حمله بسیار نامحتمل است
- 0x02 = حمله غیرمحتمل است
- 0x03 = احتمال وقوع حمله وجود دارد
- 0x04 = حمله محتمل است
- 0x05 = حمله بسیار محتمل است
- 0x06 = حمله بهشدت محتمل است
- 0xff = نامشخص
- ToA/ToD -- تفاضل زمان رسیدن منهای زمان خروج (علامتدار ۱۶ بیتی). مقدار 0x8000 = اندازهگیری در دسترس نیست.
- PCT1/PCT2 -- عبارتهای تصحیح فاز (I/Q، هر کدام ۱۲ بیت). تنها در انواع خاصی از RTT حضور دارند.
حالت ۲ -- فاصلهسنجی مبتنی بر فاز (PBR / تبادل تن)
حالت ۲ تنها را برای اندازهگیری فاز با دقت بالا مبادله میکند. چندین مسیر آنتن میتوانند بهطور همزمان اندازهگیری شوند.
فیلدهای گزارششده:
- Antenna Permutation Index -- الگوی تعویض آنتن استفادهشده را مشخص میکند.
- PCT (به ازای هر مسیر آنتن) -- عبارت تصحیح فاز با مولفه I (بیتهای 0 تا 11) و مولفه Q (بیتهای 12 تا 23).
- Tone Quality Indicator -- نیمبایت پایین:
- 0x00 = کیفیت بالا
- 0x01 = کیفیت متوسط
- 0x02 = کیفیت پایین
- 0x03 = در دسترس نیست
نیمبایت بالا (شکاف افزونه تن):
- 0x00 = شکاف افزونه تن نیست
- 0x01 = شکاف افزونه تن است، تنی مورد انتظار نیست
- 0x02 = شکاف افزونه تن است، تن مورد انتظار است
حالت ۳ -- ترکیب RTT + تن (PBR)
حالت ۳ حالتهای ۱ و ۲ را در یک گام ترکیب میکند. فیلدهای اولیه با حالت ۱ مطابقت دارند (کیفیت، NADM، RSSI، ToA/ToD، آنتن)، که بهدنبال آنها دادههای تن حالت ۲ میآیند.
فرمت دادههای نتایج زیررویداد (Subevent Result Data Format)
هر رویداد نتیجه زیررویداد حاوی فیلدهای وضعیتی است که نشان میدهند آیا رویه و زیررویداد بهطور عادی کامل شدهاند یا خیر.
وضعیت اتمام رویه (Procedure Done Status):
- 0x00 -- تمام نتایج برای این رویه CS کامل است
- 0x01 -- نتایج جزئی، رویدادهای بیشتری در پی خواهد آمد
- 0x0f -- تمام رویههای بعدی لغو شدند
وضعیت اتمام زیررویداد (Subevent Done Status):
- 0x00 -- تمام نتایج برای این زیررویداد کامل است
- 0x01 -- نتایج جزئی، رویداد ادامه در پی خواهد آمد
- 0x0f -- زیررویداد جاری لغو شد
دلیل لغو (Abort Reason) (بایت فشرده):
نیمبایت پایین (دلیل لغو رویه):
- 0x00 -- عدم لغو
- 0x01 -- لغوشده توسط میزبان محلی یا درخواست از راه دور
- 0x02 -- نقشه کانال کمتر از ۱۵ کانال دارد
- 0x03 -- لحظه بهروزرسانی نقشه کانال منقضی شده است
- 0x0f -- دلیل نامشخص
نیمبایت بالا (دلیل لغو زیررویداد):
- 0x00 -- عدم لغو
- 0x01 -- لغوشده توسط میزبان محلی یا درخواست از راه دور
- 0x02 -- هیچ همگامسازی CS_SYNC (حالت ۰) دریافت نشد
- 0x03 -- تداخل زمانبندی یا کمبود منابع
- 0x0f -- دلیل نامشخص
ماشین حالت سنجش کانال (CS State Machine)
یک پیکربندی CS در هر دستگاه بین این حالتها گذار میکند. حالت بهطور صریح در یک فیلد منفرد گزارش نمیشود -- بلکه از توالی دستورات و رویدادهای HCI استنباط میگردد:
┌──────────┐
│ IDLE │
└────┬─────┘
│ LE CS Read Local/Remote Supported Capabilities
│ LE CS Security Enable Complete
│ LE CS Set Default Settings
▼
┌──────────────────┐
│ CAPABILITIES │ Both devices' CS parameters are known.
│ EXCHANGED │ Security is established.
└────┬─────────────┘
│ LE CS Create Config
│ ──► LE CS Config Complete (status=0x00)
▼
┌──────────────────┐
│ CONFIGURED │ Config ID N exists with negotiated params.
│ (config_id=N) │ Can create up to 4 configs simultaneously.
└────┬─────────────┘
│ LE CS Set Procedure Parameters
▼
┌──────────────────┐
│ PARAMETERS SET │ Scheduling and antenna params are locked.
│ (config_id=N) │
└────┬─────────────┘
│ LE CS Procedure Enable (enable=1)
│ ──► LE CS Procedure Enable Complete (state=1)
▼
┌──────────────────┐
│ PROCEDURE │ Controller is actively measuring.
│ RUNNING │ Subevent Result events stream in.
│ (config_id=N) │
└────┬─────────────┘
│ LE CS Procedure Enable (enable=0)
│ ──► LE CS Procedure Enable Complete (state=0)
▼
┌──────────────────┐
│ CONFIGURED │ Config still exists, can re-enable.
│ (config_id=N) │
└────┬─────────────┘
│ LE CS Remove Config
▼
┌──────────┐
│ IDLE │
└──────────┘
چندین پیکربندی میتوانند همزمان وجود داشته باشند. حذف یک پیکربندی بر بقیه اثری نمیگذارد.
توالی نمونه راهاندازی سنجش کانال (Typical CS Setup Sequence)
یک نشست کامل اندازهگیری فاصله CS صرفاً از طریق HCI از این جریان پیروی میکند. ستون چپ دستورات Host ──► Controller را نشان میدهد، و ستون راست حالت حاصل را نمایش میدهد:
Host ──► Controller State
═══════════════════════════════════════════════════════════════
LE CS Read Local Supported Capabilities IDLE
◄── Command Complete (capabilities)
│
LE CS Read Remote Supported Capabilities │
◄── Command Status │
◄── LE CS Read Remote Supp. Cap. Complete │
│
LE CS Security Enable │
◄── Command Status │
◄── LE CS Security Enable Complete │
│
LE CS Set Default Settings │
◄── Command Complete ▼
CAPABILITIES EXCHANGED
LE CS Read Remote FAE Table (optional) │
◄── LE CS Read Remote FAE Complete │
│
LE CS Set Channel Classification (optional) │
◄── Command Complete │
│
LE CS Create Config (config_id=0) │
◄── Command Status │
◄── LE CS Config Complete ▼
CONFIGURED (id=0)
LE CS Set Procedure Parameters (config_id=0) │
◄── Command Complete ▼
PARAMETERS SET (id=0)
LE CS Procedure Enable (id=0, enable=1) │
◄── Command Status │
◄── LE CS Procedure Enable Complete (state=1)▼
PROCEDURE RUNNING (id=0)
◄── LE CS Subevent Result ┐ │
◄── LE CS Subevent Result Cont. │(repeated) │
◄── LE CS Subevent Result ┘ │
│
LE CS Procedure Enable (id=0, enable=0) │
◄── Command Status │
◄── LE CS Procedure Enable Complete (state=0)▼
CONFIGURED (id=0)
LE CS Remove Config (id=0) (optional) │
◄── Command Status ▼
IDLE
گامهای بالاتر از اولین LE CS Create Config مراحل راهاندازی یکباره به ازای هر اتصال هستند. چرخه پیکربندی / پارامترها / فعالسازی / غیرفعالسازی میتواند تکرار شود.
حالت آزمون سنجش کانال (CS Test Mode)
حالت آزمون CS به کنترلکننده امکان میدهد تا رویههای CS را بدون نیاز به یک دستگاه راه دور، برای مقاصد ساخت و اعتبارسنجی اجرا کند:
< HCI Command: LE CS Test (0x08|0x0095) plen 34 #400 [hci0]
Main Mode Type: 0x01
Sub Mode Type: 0xff
Main Mode Repetition: 0
Mode 0 Steps: 3
Role: Initiator (0x00)
RTT Type: 0x01
CS Sync PHY: LE 2M (0x01)
CS Sync Antenna Selection: 0x01
Subevent Len: 5000 us
Subevent Interval: 0
Max Num Subevents: 1
Transmit Power Level: 10
T_IP1 Time: 30 us
T_IP2 Time: 30 us
T_FCS Time: 50 us
T_PM Time: 10 us
T_SW Time: 0 us
Tone Antenna Config Selection: 0x01
SNR Control Initiator: 0x00
SNR Control Reflector: 0x00
DRBG Nonce: 0x0000
Channel Map Repetition: 1
Override Config: 0x0000
> HCI Event: Command Complete (0x0e) plen 5 #401 [hci0]
LE CS Test (0x08|0x0095) ncmd 1
Status: Success (0x00)
نتایج مانند رویدادهای عادی LE CS Subevent Result دریافت میشوند. آزمون با دستور زیر خاتمه مییابد:
< HCI Command: LE CS Test End (0x08|0x0096) plen 0 #450 [hci0]
> HCI Event: LE Meta Event (0x3e) plen 1 #451 [hci0]
LE CS Test End Complete (0x33)
Status: Success (0x00)
مدیریت خطای سنجش کانال (Channel Sounding Error Handling)
- شکست در فعالسازی امنیت (Security Enable fails)
- اتصال باید پیش از CS Security Enable رمزنگاری شده باشد. بررسی کنید که جفتسازی SMP و LE Encrypt تکمیل شده باشند. همچنین بررسی کنید که هر دو دستگاه پشتیبانی از CS را در مجموعه ویژگیهای LE خود اعلان کرده باشند.
- خطا در رویداد Config Complete (Config Complete with error)
- کنترلکننده ممکن است پیکربندی را در صورتی که پارامترهای درخواستی با اشتراک قابلیتهای هر دو دستگاه ناسازگار باشد، رد کند. بررسی کنید که حالت اصلی، PHY و پارامترهای زمانبندی درون محدوده پشتیبانیشده هر دو دستگاه قرار گیرند.
- بیش از حد کوچک بودن نقشه کانال (Channel map too small)
- سنجش کانال (CS) به حداقل ۱۵ کانال نیاز دارد. اگر دستهبندی کانال یا تداخل فرکانسی کانالهای زیادی را حذف کند، رویه با دلیل لغو 0x02 (نیمبایت پایین) لغو خواهد شد.
- عدم دریافت همگامسازی حالت ۰ (No Mode 0 sync received)
- دلیل لغو زیررویداد 0x02 (نیمبایت بالا) به این معناست که بسته همگامسازی حالت ۰ آغازگر توسط بازتابدهنده دریافت نشده است (یا بالعکس). این امر نشاندهنده یک مشکل RF، از دست رفتن زمانبندی، یا خارج از برد بودن دستگاه است.
- رویه توسط میزبان لغو شد (Procedure aborted by host)
- دلیل لغو 0x01 در هر یک از نیمبایتها به این معناست که میزبان محلی یا دستگاه راه دور درخواست خاتمه داده است، که معمولاً از طریق Procedure Enable با مقدار enable=0 صورت میگیرد.
- عدم در دسترس بودن ToA/ToD (مقدار 0x8000)
- کنترلکننده نتوانست یک اندازهگیری زمانی معتبر برای این گام محاسبه کند. این وضعیت با سیگنالهای ضعیف یا زمانی که نشانی دسترسی CS تشخیص داده نشود (کیفیت بسته = 0x02) رایج است.
سرویس فاصلهسنجی (RAS) / نمایه فاصلهسنجی (RAP) (RANGING SERVICE (RAS) / RANGING PROFILE (RAP))
سرویس فاصلهسنجی (RAS) یک سرویس GATT است که دادههای اندازهگیری CS را در لایه کاربرد میان دستگاهها منتقل میکند. این سرویس روند CS در سطح HCI را با ارائه روشی استاندارد جهت تبادل، تأیید دریافت و بازیابی نتایج فاصلهسنجی روی ATT تکمیل میکند. نمایه فاصلهسنجی (RAP) نحوه کشف و تعامل یک دستگاه با RAS روی دستگاه دوردست را تعریف میکند.
ابزار btmon با مشاهده عملیاتهای ATT روی شناسههای یکتای سراسری (UUIDهای) مربوط به RAS، تمام مشخصههای RAS را به صورت خودکار رمزگشایی میکند.
شناسه یکتای سراسری (UUID) سرویس RAS: 0x185B
مشخصههای RAS (RAS Characteristics)
| مشخصه (Characteristic) | شناسه یکتا (UUID) | ویژگیها (Properties) | توضیحات (Description) |
| RAS Features | 0x2C14 | Read | بیتماسک قابلیتهای پشتیبانیشده RAS |
| RAS Real-time Ranging Data | 0x2C15 | Notify, Indicate | پخش زنده نتایج فاصلهسنجی همزمان با تولید آنها |
| RAS On-demand Ranging Data | 0x2C16 | Notify, Indicate | نتایج فاصلهسنجی بازیابیشده برحسب تقاضا |
| RAS Control Point | 0x2C17 | Write Without Response, Indicate | رابط دستوری جهت بازیابی دادهها و فیلتر کردن |
| RAS Ranging Data Ready | 0x2C18 | Read, Notify, Indicate | نشاندهنده در دسترس بودن یک مجموعه داده فاصلهسنجی جدید |
| RAS Ranging Data Overwritten | 0x2C19 | Read, Notify, Indicate | نشاندهنده بازنویسی شدن یک مجموعه داده ذخیرهشده |
تمام مشخصهها به جز RAS Features از توصیفگرهای پیکربندی مشخصه کلاینت (CCC) برای فعالسازی اعلانها (Notifications) و نشانهها (Indications) استفاده میکنند. ساختار معمول صفات GATT در مجموع از ۱۸ هندل استفاده میکند.
ویژگیها و قابلیتهای RAS (RAS Feature and Capabilities)
مشخصه RAS Features یک بیتماسک ۴ بایتی است که کلاینت جهت آگاهی از قابلیتهای سرور آن را میخواند:
> ACL Data RX: Handle 2048 flags 0x02 dlen 11 #200 [hci0]
ATT: Read Response (0x0b) len 4
Handle: 0x0003
Features: 0x0000000f
Real-time Ranging Data (0x00000001)
Retrieve Lost Ranging Data Segments (0x00000002)
Abort Operation (0x00000004)
Filter Ranging Data (0x00000008)
بیتهای ویژگیها:
- بیت ۰ -- دادههای فاصلهسنجی درلحظه (Real-time Ranging Data): سرور میتواند همزمان با اجرای روندهای CS، نتایج را از طریق مشخصه Real-time Ranging Data پخش کند.
- بیت ۱ -- بازیابی قطعات از دست رفته دادههای فاصلهسنجی (Retrieve Lost Ranging Data Segments): کلاینت میتواند ارسال مجدد قطعات داده مفقودشده را درخواست کند.
- بیت ۲ -- لغو عملیات (Abort Operation): کلاینت میتواند انتقال داده در حال انجام را لغو کند.
- بیت ۳ -- فیلتر کردن دادههای فاصلهسنجی (Filter Ranging Data): کلاینت میتواند مشخص کند کدام فیلدها در اعلانهای دادههای فاصلهسنجی گنجانده شوند.
دادههای فاصلهسنجی RAS آماده است (RAS Ranging Data Ready)
هنگامی که یک روند CS کامل شده و نتایج ذخیره میشوند، سرور به کلاینت اطلاع میدهد که دادهها برای بازیابی آماده هستند:
> ACL Data RX: Handle 2048 flags 0x02 dlen 9 #250 [hci0]
ATT: Handle Value Notification (0x1b) len 2
Handle: 0x000e
Counter: 42
مقدار شمارنده (Counter)، مجموعه داده فاصلهسنجی خاص را مشخص میکند. کلاینت از این شمارنده در دستورات بعدی نقطه کنترل (Control Point) برای درخواست یا تأیید دریافت (ACK) دادهها استفاده میکند.
دادههای فاصلهسنجی RAS بازنویسی شدند (RAS Ranging Data Overwritten)
اگر بافر سرور پر شود و نتایج قدیمیتر دور ریخته شوند، این مشخصه به کلاینت اطلاع میدهد:
> ACL Data RX: Handle 2048 flags 0x02 dlen 9 #260 [hci0]
ATT: Handle Value Notification (0x1b) len 2
Handle: 0x0011
Overwritten Count: 38
این اعلان به کلاینت اعلام میکند که دادههای فاصلهسنجی با مقدار شمارنده ۳۸ (و احتمالاً پیش از آن) بازنویسی شدهاند و دیگر امکان بازیابی آنها وجود ندارد.
نقطه کنترل RAS (RAS Control Point)
نقطه کنترل RAS (RAS Control Point) رابط دستوری برای مدیریت انتقال دادههای فاصلهسنجی است. کلاینت دستورات را مینویسد و سرور از طریق نشانهها (Indications) روی همان مشخصه پاسخ میدهد.
کدهای دستوری (Opcodes):
| کد دستوری (Opcode) | دستور (Command) | توضیحات (Description) |
| 0x00 | Get Ranging Data | درخواست انتقال برحسب تقاضای یک مجموعه داده خاص |
| 0x01 | ACK Ranging Data | تأیید دریافت یک مجموعه داده |
| 0x02 | Retrieve Lost Ranging Data Segments | درخواست مجدد قطعات مفقودشده مشخص |
| 0x03 | Abort Operation | لغو انتقال داده در حال انجام |
| 0x04 | Set Filter | پیکربندی فیلدهای داده گنجاندهشده |
Get Ranging Data -- درخواست انتقال یک مجموعه داده ذخیرهشده را ارسال میکند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 10 #270 [hci0]
ATT: Write Command (0x52) len 3
Handle: 0x000b
Opcode: Get Ranging Data (0x00)
Ranging Counter: 0x002a
پس از این دستور، سرور دادهها را به صورت توالیای از اعلانها روی مشخصه دادههای فاصلهسنجی برحسب تقاضا (RAS On-demand Ranging Data با شناسه 0x2C16) ارسال میکند.
ACK Ranging Data -- دریافت کامل یک مجموعه داده توسط کلاینت را تأیید میکند و به سرور اجازه میدهد بافر مربوطه را آزاد کند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 10 #290 [hci0]
ATT: Write Command (0x52) len 3
Handle: 0x000b
Opcode: ACK Ranging Data (0x01)
Ranging Counter: 0x002a
Retrieve Lost Ranging Data Segments -- درخواست ارسال مجدد قطعات مشخصی را که دریافت نشده یا مخدوش شدهاند ارسال میکند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 12 #295 [hci0]
ATT: Write Command (0x52) len 5
Handle: 0x000b
Opcode: Retrieve Lost Ranging Data Segments (0x02)
Ranging Counter: 0x002a
First Segment Index: 3
Last Segment Index: 5
مقدار اندیس آخرین قطعه برابر با 0xFF به معنای «تمام قطعات باقیمانده از اندیس نخست به بعد» است.
Abort Operation -- هرگونه انتقال داده در حال انجام را لغو میکند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 8 #298 [hci0]
ATT: Write Command (0x52) len 1
Handle: 0x000b
Opcode: Abort Operation (0x03)
Set Filter -- مشخص میکند کدام فیلدها در اعلانهای دادههای فاصلهسنجی گنجانده شوند:
< ACL Data TX: Handle 2048 flags 0x00 dlen 10 #265 [hci0]
ATT: Write Command (0x52) len 3
Handle: 0x000b
Opcode: Set Filter (0x04)
Filter Configuration: 0x0001
Mode: 1
Filter Bit Mask: 0x0000
پیکربندی فیلتر یک مقدار ۱۶ بیتی است: بیتهای [1:0] حالت فیلتر را انتخاب میکنند و بیتهای [15:2] یک بیتماسک برای فیلدها فراهم میسازند.
قالب دادههای فاصلهسنجی (Ranging Data Format)
هر دو مشخصه دادههای فاصلهسنجی درلحظه (0x2C15) و برحسب تقاضا (0x2C16) از یک قالب داده قطعهبندیشده مشابه استفاده میکنند. مجموعههای داده حجیم در چندین اعلان ATT تقسیم میشوند.
سرآیند قطعهبندی (Segmentation Header) (۱ بایت، موجود در تمام اعلانها):
> ACL Data RX: Handle 2048 flags 0x02 dlen 30 #275 [hci0]
ATT: Handle Value Notification (0x1b) len 25
Handle: 0x0005
Segmentation Header: 0x01
First Segment: True
Last Segment: False
Segment Index: 0
Ranging Data Body:
Ranging Counter: 0x02a
Configuration ID: 0
Selected TX Power: 12 dBm
Antenna Paths Mask: 0x03
Antenna Path 1 (0x01)
Antenna Path 2 (0x02)
Subevent #0:
Start ACL Connection Event: 1200
Frequency Compensation: 150 (0.01 ppm)
Ranging Done Status: Partial results (0x1)
Subevent Done Status: All results complete (0x0)
Ranging Abort Reason: No abort (0x0)
Subevent Abort Reason: No abort (0x0)
Reference Power Level: -20 dBm
Number of Steps Reported: 8
Remaining Ranging Data Segment: ...
فیلدهای سرآیند قطعهبندی:
- First Segment (بیت ۰) -- مقدار True برای اولین اعلان یک مجموعه داده. تنها نخستین قطعه حاوی Ranging Header است.
- Last Segment (بیت ۱) -- مقدار True برای اعلان پایانی. هنگامی که هر دو بیت تنظیم شده باشند، کل مجموعه داده در یک اعلان قرار میگیرد.
- Segment Index (بیتهای [7:2]) -- اندیس ترتیبی برای بازترکیب قطعات.
Ranging Header (۴ بایت، تنها در نخستین قطعه):
- Ranging Counter (بیتهای [11:0]) -- با شمارنده اعلان Data Ready مطابقت دارد؛ نمونه اجرای روند CS را مشخص میکند.
- Configuration ID (بیتهای [15:12]) -- شناسه پیکربندی CS (۰ تا ۳) که برای این اندازهگیری استفاده شده است.
- Selected TX Power (۱ بایت، علامتدار) -- توان ارسال واقعی استفادهشده، بر حسب dBm.
- Antenna Paths Mask (۱ بایت) -- بیتماسکی که نشان میدهد کدام مسیرهای آنتن دارای داده هستند: بیت ۰ = مسیر ۱، بیت ۱ = مسیر ۲ و غیره.
Subevent Header (به ازای هر زیررویداد درون دادههای فاصلهسنجی):
- Start ACL Connection Event -- شمارنده رویداد اتصال ACL که این زیررویداد CS در آن آغاز شده است.
- Frequency Compensation -- انحراف فرکانسی اندازهگیریشده برحسب واحدهای 0.01 ppm (علامتدار ۱۶ بیتی).
- Ranging Done Status -- کدهایی مشابه با نتایج زیررویداد HCI: مقدار 0x0 = کامل، 0x1 = جزئی، 0xF = لغوشده.
- Subevent Done Status -- مقدار 0x0 = کامل، 0xF = لغوشده.
- Ranging/Subevent Abort Reason -- کدهای دلیل لغو مشابه با HCI: مقدار 0x0 = بدون لغو، 0x1 = درخواست میزبان/دستگاه دوردست، 0x2 = نقشه کانال / عدم همگامسازی، 0x3 = زمانبندی، 0xF = نامشخص.
- Reference Power Level -- مرجع RSSI بر حسب dBm (علامتدار).
- Number of Steps Reported -- تعداد نتایج گام CS که در ادامه میآیند.
دادههای گام که پس از سرآیند زیررویداد میآیند، از همان قالب مختص هر حالت در رویدادهای نتایج زیررویداد HCI CS (حالتهای ۰ تا ۳) استفاده میکنند که در بخش مربوط به حالتهای گام CS در بالا توضیح داده شد.
قطعات ادامهدهنده (Continuation segments) تنها شامل سرآیند قطعهبندی هستند که به دنبال آنها بایتهای خام دادههای فاصلهسنجی قرار میگیرند و با قطعات پیشین بازترکیب میشوند.
ماشین حالت انتقال دادههای RAS (RAS Data Transfer State Machine)
انتقال دادههای RAS برای یک مجموعه داده فاصلهسنجی واحد میان این حالتها جابهجا میشود:
┌───────────────┐
│ IDLE │ No active data transfer.
└─────┬─────────┘
│ Server: CS procedure completes (HCI level)
│ Server: notifies Ranging Data Ready (counter=N)
▼
┌───────────────┐
│ DATA READY │ Dataset N is buffered on server.
│ (counter=N) │ Client has been notified.
└─────┬─────────┘
│ Client writes: Get Ranging Data (counter=N)
│ ── OR ── (real-time mode: automatic push)
▼
┌───────────────┐
│ TRANSFERRING │ Server sends segmented notifications.
│ (counter=N) │ Segment Index increments: 0, 1, 2, ...
└─────┬──────┬──┘
│ │ Segment lost? Client writes:
│ │ Retrieve Lost Segments (counter=N, first, last)
│ │ Server re-sends missing segments.
│ │ (loops back to TRANSFERRING)
│ │
│ │ Client writes: Abort Operation
│ └──────────────────────┐
│ Last Segment received │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ COMPLETE │ │ ABORTED │
│ (counter=N) │ └───────┬───────┘
└─────┬─────────┘ │
│ Client writes: │
│ ACK Ranging Data │
│ (counter=N) │
▼ ▼
┌───────────────┐
│ IDLE │ Server may free buffer for counter=N.
└───────────────┘
اگر بافر سرور پیش از بازیابی دادهها توسط کلاینت پر شود، یک اعلان Ranging Data Overwritten ارسال میشود و مجموعه داده مستقیماً از حالت DATA READY به وضعیت بازنویسیشده (از دست رفته) منتقل میگردد.
جریان معمول دادههای RAS (Typical RAS Data Flow)
یک نشست کامل RAS برای بازیابی دادهها برحسب تقاضا:
1. Client discovers RAS (UUID 0x185B) via GATT primary service discovery
2. Client reads RAS Features (0x2C14) to learn capabilities
3. Client enables CCC notifications on:
- RAS Ranging Data Ready (0x2C18)
- RAS Ranging Data Overwritten (0x2C19)
- RAS On-demand Ranging Data (0x2C16) or
RAS Real-time Ranging Data (0x2C15)
4. CS procedure runs (HCI level)
5. Server notifies Ranging Data Ready with counter=N
6. Client writes Control Point: Get Ranging Data (counter=N)
7. Server sends On-demand Ranging Data notifications (segmented)
8. Client writes Control Point: ACK Ranging Data (counter=N)
برای پخش زنده درلحظه، مرحله ۶ نادیده گرفته میشود -- سرور به محض تکمیل هر زیررویداد CS، با استفاده از همان قالب قطعهبندیشده دادهها را روی مشخصه دادههای فاصلهسنجی درلحظه (Real-time Ranging Data با شناسه 0x2C15) ارسال (Push) میکند.
در صورتی که قطعاتی از دست بروند (برای مثال به دلیل محدودیتهای ATT MTU یا از دست رفتن اعلانها)، کلاینت از دستور Retrieve Lost Ranging Data Segments برای درخواست ارسال مجدد اندیسهای قطعات مشخص استفاده میکند.
جریان ترکیبی HCI + GATT (Combined HCI + GATT Flow)
نمودار زیر جدول زمانی تداخل کامل عملیاتهای HCI CS و عملیاتهای GATT RAS را همانطور که در ردگیری btmon ظاهر میشوند نشان میدهد. ستون سمت چپ ترافیک HCI (< HCI / > HCI)، ستون میانی ترافیک GATT ATT (< ACL / > ACL) و ستون سمت راست وضعیت ترکیبی را نشان میدهد:
HCI (CS) GATT (RAS) State
══════════════════════════════════════════════════════════════════════════
--- One-time connection setup ---
< LE CS Read Local Supp. Cap. IDLE
> Command Complete │
< LE CS Read Remote Supp. Cap. │
> Command Status │
> LE CS Read Remote Supp. │
Cap. Complete │
< LE CS Security Enable │
> Command Status │
> LE CS Security Enable │
Complete │
< LE CS Set Default Settings │
> Command Complete ▼
CAPS EXCHANGED
< ATT: Find By Type Value │
(RAS UUID 0x185B) │
> ATT: Find By Type Value │
Response │
< ATT: Read Request │
(RAS Features 0x2C14) │
> ATT: Read Response │
Features: 0x0000000f │
< ATT: Write Request │
(CCC: Ready 0x2C18) │
> ATT: Write Response │
< ATT: Write Request │
(CCC: On-demand 0x2C16) │
> ATT: Write Response ▼
RAS READY
--- Per-measurement cycle (repeatable) ---
< LE CS Create Config (id=0) │
> Command Status │
> LE CS Config Complete ▼
CONFIGURED (id=0)
< LE CS Set Proc. Params (id=0) │
> Command Complete ▼
PARAMS SET (id=0)
< LE CS Proc. Enable │
(id=0, enable=1) │
> Command Status │
> LE CS Proc. Enable │
Complete (state=1) ▼
PROCEDURE RUNNING
> LE CS Subevent Result ─┐ │
> LE CS Subevent Result │ (measurement data │
Continue │ streams from │
> LE CS Subevent Result │ controller) │
> LE CS Subevent Result ─┘ │
│
> LE CS Subevent Result │
(Procedure Done=0x00) ▼
PROCEDURE COMPLETE
> ATT: Notification │
(Data Ready 0x2C18) │
Counter: N ▼
DATA READY (N)
< ATT: Write Command │
(Control Point 0x2C17) │
Get Ranging Data │
Counter: N ▼
TRANSFERRING (N)
> ATT: Notification │
(On-demand 0x2C16) │
Seg[0]: First=T Last=F │
Ranging Header + data │
> ATT: Notification │
(On-demand 0x2C16) │
Seg[1]: First=F Last=F │
> ATT: Notification │
(On-demand 0x2C16) │
Seg[2]: First=F Last=T ▼
TRANSFER COMPLETE (N)
< ATT: Write Command │
(Control Point 0x2C17) │
ACK Ranging Data │
Counter: N ▼
IDLE (buffer freed)
--- Cleanup (optional) ---
< LE CS Remove Config (id=0)
> Command Status IDLE
جریان پخش درلحظه (Real-time Streaming Flow)
هنگامی که سرور از دادههای فاصلهسنجی درلحظه پشتیبانی میکند (بیت ۰ در ویژگیها)، نتایج به محض تکمیل زیررویدادهای CS و بدون انتظار برای درخواست Get Ranging Data فوراً ارسال میشوند:
HCI (CS) GATT (RAS) State
══════════════════════════════════════════════════════════════════════════
< LE CS Proc. Enable PARAMS SET
(id=0, enable=1)
> LE CS Proc. Enable Complete ▼
PROCEDURE RUNNING
> LE CS Subevent Result ──┐
│ > ATT: Notification
│ (Real-time 0x2C15)
│ Seg[0]: First=T Last=T
│ Ranging Header +
│ subevent data
> LE CS Subevent Result ──┤
│ > ATT: Notification
│ (Real-time 0x2C15)
│ Seg[0]: First=T Last=F
│ > ATT: Notification
│ (Real-time 0x2C15)
│ Seg[1]: First=F Last=T
> LE CS Subevent Result ──┘
> ATT: Notification
(Real-time 0x2C15)
...
> LE CS Subevent Result │
(Procedure Done=0x00) ▼
PROCEDURE COMPLETE
< ATT: Write Command
ACK Ranging Data
Counter: N ▼
IDLE
در حالت درلحظه، هر رویداد نتیجه زیررویداد HCI بلافاصله یک یا چند اعلان GATT را راهاندازی میکند. شمارنده فاصلهسنجی (Ranging Counter) در سرآیند دادهها با هر روند افزایش مییابد. اگر یک قطعه اعلان از دست برود، کلاینت میتواند پس از پایان روند از دستور Retrieve Lost Segments استفاده کند (در صورتی که بیت ۱ در ویژگیها تنظیم شده باشد).
جریان بازیابی قطعات از دست رفته (Lost Segment Recovery Flow)
هنگامی که در حین انتقال قطعاتی از دست میروند، کلاینت درخواست ارسال مجدد میدهد:
GATT (RAS) State
══════════════════════════════════════════════════════════════
> ATT: Notification (On-demand 0x2C16) TRANSFERRING
Seg[0]: First=T Last=F ── received
> ATT: Notification (On-demand 0x2C16)
Seg[1]: First=F Last=F ── received
│
Seg[2] ── LOST (not received) │
│
> ATT: Notification (On-demand 0x2C16) │
Seg[3]: First=F Last=T ── received │
│
(Client detects gap: Seg[2] missing) ▼
INCOMPLETE
< ATT: Write Command (Control Point 0x2C17)
Retrieve Lost Ranging Data Segments
Counter: N
First Segment Index: 2
Last Segment Index: 2 ▼
RECOVERING
> ATT: Notification (On-demand 0x2C16)
Seg[2]: First=F Last=F ── re-sent ▼
TRANSFER COMPLETE
< ATT: Write Command (Control Point 0x2C17)
ACK Ranging Data
Counter: N ▼
IDLE
مشکلات متداول RAS (RAS Common Issues)
- خواندن ویژگیها مقدار 0x00000000 را برمیگرداند (Features read returns 0x00000000)
- سرور از هیچ ویژگی اختیاری RAS پشتیبانی نمیکند. تنها بازیابی پایه دادهها برحسب تقاضا از طریق نقطه کنترل (Control Point) در دسترس است.
- اعلان آماده بودن دادههای فاصلهسنجی دریافت نشد (Ranging Data Ready not received)
- بررسی کنید که اعلانهای CCC روی هندل 0x2C18 فعال باشند. همچنین مطمئن شوید که روند CS واقعاً به پایان رسیده است -- اگر روند لغو شده باشد، هیچ اعلان Data Ready ارسال نمیشود.
- خطاهای بازترکیب قطعهبندی (Segmentation reassembly errors)
- بررسی کنید که مقادیر اندیس قطعه (Segment Index) متوالی باشند و پرچم First Segment در نخستین اعلان تنظیم شده باشد. در صورت پشتیبانی سرور (بیت ۱ در ویژگیها)، مفقود شدن یک قطعه سازوکار Retrieve Lost Segments را فعال میکند.
- دادهها پیش از بازیابی بازنویسی شدند (Data Overwritten before retrieval)
- سرور فضای بافر محدودی دارد. اگر کلاینت به سرعت دادهها را بازیابی و تأیید (ACK) نکند، مجموعههای داده قدیمیتر بازنویسی میشوند. اعلان Data Overwritten مقدار شمارنده دادههای از دست رفته را نشان میدهد.
- رد شدن نوشتن در نقطه کنترل (Control Point write rejected)
- اتصال باید رمزگذاری شده باشد. نقطه کنترل RAS به مجوز نوشتن با رمزگذاری (WRITE_ENCRYPT) نیاز دارد. بررسی کنید که جفتسازی SMP کامل شده باشد.
جریان پروتکل صوتی کلاسیک (CLASSIC AUDIO PROTOCOL FLOW)
صوت بلوتوث کلاسیک از دو نمایه اصلی استفاده میکند: A2DP برای استریم استریو با کیفیت بالا و HFP برای تماسهای صوتی. هر دو بر روی اتصالات ACL از نوع BR/EDR اجرا میشوند و از سازوکارهای انتقال متفاوتی برای دادههای صوتی استفاده میکنند -- نمایه A2DP از کانالهای رسانهای AVDTP مبتنی بر L2CAP استفاده میکند در حالی که HFP از اتصالات همگام SCO/eSCO بهره میبرد.
A2DP: توزیع پیشرفته صدا (A2DP: Advanced Audio Distribution)
نمایه A2DP از پروتکل AVDTP (پروتکل انتقال توزیع صوتی/تصویری) بر روی L2CAP برای مذاکره بر سر پارامترهای کدک (Codec) و استریم صدای با کیفیت بالا استفاده میکند. ابزار btmon سیگنالدهی AVDTP، قابلیتهای کدک و پیامهای کنترل از راه دور AVRCP را به طور کامل رمزگشایی میکند.
کانال سیگنالدهی AVDTP (AVDTP Signaling Channel)
نمایه A2DP با یک اتصال L2CAP روی PSM 25 (0x0019) آغاز میشود. نخستین اتصال L2CAP روی این PSM، سیگنالدهی AVDTP را منتقل میکند؛ دومین اتصال روی همین PSM دادههای انتقال چندرسانهای را منتقل میسازد:
< ACL Data TX: Handle 1 flags 0x00 dlen 12
L2CAP: Connection Request (0x02) ident 1 len 4
PSM: 25 (0x0019)
Source CID: 64
> ACL Data RX: Handle 1 flags 0x02 dlen 16
L2CAP: Connection Response (0x03) ident 1 len 8
Destination CID: 64
Source CID: 64
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
پس از تکمیل پیکربندی L2CAP، سیگنالدهی AVDTP روی این کانال آغاز میشود.
کشف نقطه پایانی جریان (Stream Endpoint Discovery)
شروعکننده (initiator)، نقاط پایانی جریان (SEPها) موجود روی دستگاه دوردست را کشف میکند:
< ACL Data TX: Handle 1 flags 0x00 dlen 6
Channel: 64 len 2 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Discover (0x01) Command (0x00) type 0x00 label 0 nosp 0
> ACL Data RX: Handle 1 flags 0x02 dlen 10
Channel: 64 len 6 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Discover (0x01) Response Accept (0x02) type 0x00 label 0 nosp 0
ACP SEID: 1
Media Type: Audio (0x00)
SEP Type: SNK (0x01)
In use: No
هر نقطه پایانی جریان (SEP) دارای یک شناسه SEID (شناسه نقطه پایانی جریان)، نوع رسانه و نقش (Source یا Sink) است. مقدار In use: Yes به این معناست که نقطه پایانی در حال حاضر مشغول پخش استریم است.
کشف قابلیتهای کدک (Codec Capability Discovery)
پس از کشف SEIDها، شروعکننده قابلیتهای هر نقطه پایانی را جویا میشود:
< ACL Data TX: Handle 1 flags 0x00 dlen 7
Channel: 64 len 3 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Get All Capabilities (0x0c) Command (0x00) type 0x00 label 1 nosp 0
ACP SEID: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 30
Channel: 64 len 26 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Get All Capabilities (0x0c) Response Accept (0x02) type 0x00 label 1 nosp 0
Service Category: Media Transport (0x01)
Service Category: Media Codec (0x07)
Media Type: Audio (0x00)
Media Codec: SBC (0x00)
Frequency: 0xf0
16000
32000
44100
48000
Channel Mode: 0x0f
Mono
Dual Channel
Stereo
Joint Stereo
Block Length: 0xf0
4
8
12
16
Subbands: 0x0c
4
8
Allocation Method: 0x03
SNR
Loudness
Minimum Bitpool: 2
Maximum Bitpool: 53
Service Category: Content Protection (0x04)
Content Protection Type: SCMS-T (0x0002)
Service Category: Delay Reporting (0x08)
پاسخهای قابلیت، تمام مقادیر پشتیبانیشده را به عنوان ماسک بیتی (bitmask) فهرست میکنند. دستهبندیهای کلیدی سرویس:
- Media Transport (0x01) -- همیشه وجود دارد، نشان میدهد که نقطه پایانی از یک کانال انتقال چندرسانهای پشتیبانی میکند
- Media Codec (0x07) -- نوع کدک (Codec) و پارامترهای پشتیبانیشده
- Content Protection (0x04) -- محافظت از کپی (SCMS-T یا DTCP)
- Delay Reporting (0x08) -- نقطه پایانی از گزارش تاخیر زمانی پشتیبانی میکند
کدکهای پشتیبانیشده (Supported Codecs)
ابزار btmon چندین کدک (Codec) A2DP را رمزگشایی میکند. هر کدام قالب پارامتر متفاوتی دارند.
SBC (کدک الزامی A2DP):
Media Codec: SBC (0x00) Frequency: 44100 (0x20) Channel Mode: Joint Stereo (0x01) Block Length: 16 (0x10) Subbands: 8 (0x04) Allocation Method: Loudness (0x01) Minimum Bitpool: 2 Maximum Bitpool: 53
AAC (MPEG-2,4):
Media Codec: MPEG-2,4 AAC (0x02) Object Type: MPEG-4 AAC LC (0x40) Frequency: 44100 (0x0100) Channels: 2 (0x04) Bitrate: 256000bps VBR: No
aptX (شرکت Qualcomm، مختص سازنده):
Media Codec: Non-A2DP (0xff)
Vendor ID: Qualcomm Technologies International, Ltd. (APT) (0x0000004f)
Vendor Specific Codec ID: aptX (0x0001)
Frequency: 44100 (0x20)
Channel Mode: Stereo (0x02)
aptX HD (شرکت Qualcomm، مختص سازنده):
Media Codec: Non-A2DP (0xff)
Vendor ID: Qualcomm Technologies, Inc. (0x000000d7)
Vendor Specific Codec ID: aptX HD (0x0024)
Frequency: 44100 (0x20)
Channel Mode: Stereo (0x02)
LDAC (شرکت Sony، مختص سازنده):
Media Codec: Non-A2DP (0xff) Vendor ID: Sony Corporation (0x0000012d) Vendor Specific Codec ID: LDAC (0x00aa)
کدکهای اختصاصی سازنده به صورت Non-A2DP (0xff) همراه با Vendor ID و Codec ID رمزگشاییشده نشان داده میشوند. پاسخهای قابلیت، تمام مقادیر پشتیبانیشده را به عنوان ماسک بیتی فهرست میکنند؛ پاسخهای پیکربندی تنها مقدار انتخابشده را نشان میدهند.
پیکربندی جریان (Stream Configuration)
پس از انتخاب کدک و پارامترها، شروعکننده دستور Set Configuration را ارسال میکند:
< ACL Data TX: Handle 1 flags 0x00 dlen 20
Channel: 64 len 16 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Set Configuration (0x03) Command (0x00) type 0x00 label 2 nosp 0
ACP SEID: 1
INT SEID: 1
Service Category: Media Transport (0x01)
Service Category: Media Codec (0x07)
Media Type: Audio (0x00)
Media Codec: SBC (0x00)
Frequency: 44100 (0x20)
Channel Mode: Joint Stereo (0x01)
Block Length: 16 (0x10)
Subbands: 8 (0x04)
Allocation Method: Loudness (0x01)
Minimum Bitpool: 2
Maximum Bitpool: 53
> ACL Data RX: Handle 1 flags 0x02 dlen 6
Channel: 64 len 2 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Set Configuration (0x03) Response Accept (0x02) type 0x00 label 2 nosp 0
پاسخهای پیکربندی به جای فهرستهای ماسک بیتی، مقادیر تکی انتخابشده را نشان میدهند. ACP SEID نقطه پایانی راه دور و INT SEID نقطه پایانی محلی است.
اگر پیکربندی رد شود:
> ACL Data RX: Handle 1 flags 0x02 dlen 8
Channel: 64 len 4 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Set Configuration (0x03) Response Reject (0x03) type 0x00 label 2 nosp 0
Service Category: Media Codec (0x07)
Error code: Unsupported Configuration (0x29)
کدهای خطای متداول AVDTP:
| کد | نام | مفهوم |
| 0x01 | Bad Header Format | سرآیند AVDTP معیوب است |
| 0x11 | Bad ACP SEID | شناسه نقطه پایانی ناشناخته است |
| 0x12 | SEP In Use | نقطه پایانی در حال حاضر مشغول استریم است |
| 0x13 | SEP Not In Use | نقطه پایانی پیکربندی نشده است |
| 0x29 | Unsupported Configuration | پارامترهای درخواستی پشتیبانی نمیشوند |
| 0x31 | Bad State | دستور در وضعیت فعلی معتبر نیست |
باز کردن و شروع (Open and Start)
پس از پیکربندی، جریان باز شده و سپس شروع میشود:
< ACL Data TX: Handle 1 flags 0x00 dlen 7
Channel: 64 len 3 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Open (0x06) Command (0x00) type 0x00 label 3 nosp 0
ACP SEID: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 6
Channel: 64 len 2 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Open (0x06) Response Accept (0x02) type 0x00 label 3 nosp 0
پس از موفقیتآمیز بودن Open، یک اتصال L2CAP دوم روی PSM 25 برای کانال انتقال رسانه برقرار میشود. سپس Start استریم را آغاز میکند:
< ACL Data TX: Handle 1 flags 0x00 dlen 7
Channel: 64 len 3 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Start (0x07) Command (0x00) type 0x00 label 4 nosp 0
ACP SEID: 1
> ACL Data RX: Handle 1 flags 0x02 dlen 6
Channel: 64 len 2 [PSM 25 mode Basic (0x00)] {chan 0}
AVDTP: Start (0x07) Response Accept (0x02) type 0x00 label 4 nosp 0
دادههای چندرسانهای (Media Data)
پس از Start، دادههای صوتی کدگذاریشده روی کانال انتقال چندرسانهای (دومین اتصال L2CAP روی PSM 25) جریان مییابند. btmon به طور پیشفرض محتوای بستههای دادههای چندرسانهای را رمزگشایی نمیکند -- دادههای رسانه نادیده گرفته میشوند. تنها هنگام فعال بودن فیلتر --show-a2dp-stream سرآیند کانال L2CAP قابل مشاهده است و بار مفید (payload) به عنوان دامپ هگزادسیمال خام نشان داده میشود.
ماشین وضعیت AVDTP قابل مشاهده در ردگیریها:
| وضعیت | برانگیخته توسط | شرح |
| Idle | اولیه / پاسخ Abort | هیچ جریانی پیکربندی نشده است |
| Configured | پذیرش Set Configuration | کدک و پارامترها انتخاب شدهاند |
| Open | پذیرش Open / پذیرش Suspend | کانال انتقال آماده است، در حال استریم نیست |
| Streaming | پذیرش Start | دادههای صوتی در حال جریان هستند |
| Closing | ارسال دستور Close | در حال برچیدن جریان |
| Aborting | ارسال دستور Abort | برچیدن اجباری |
تعلیق، بستن و لغو (Suspend, Close, and Abort)
دستور Suspend پخش استریم را بدون برچیدن لایه انتقال موقتاً متوقف (مکث) میکند:
AVDTP: Suspend (0x09) Command (0x00) type 0x00 label 5 nosp 0 ACP SEID: 1 AVDTP: Suspend (0x09) Response Accept (0x02) type 0x00 label 5 nosp 0
دستور Close جریان را برمیچیند (بازگشت به وضعیت Idle):
AVDTP: Close (0x08) Command (0x00) type 0x00 label 6 nosp 0 ACP SEID: 1 AVDTP: Close (0x08) Response Accept (0x02) type 0x00 label 6 nosp 0
دستور Abort برچیدن فوری را اجبار میکند:
AVDTP: Abort (0x0a) Command (0x00) type 0x00 label 7 nosp 0 ACP SEID: 1 AVDTP: Abort (0x0a) Response Accept (0x02) type 0x00 label 7 nosp 0
گزارش تاخیر زمانی (Delay Reporting)
هنگامی که گیرنده (sink) از گزارش تاخیر زمانی پشتیبانی کند، یک گزارش تاخیر (Delay Report) ارسال میکند تا فرستنده (source) را از تاخیر بازتولید و رندرینگ خود مطلع سازد:
AVDTP: Delay Report (0x0d) Command (0x00) type 0x00 label 8 nosp 0 ACP SEID: 1 Delay: 15.0ms AVDTP: Delay Report (0x0d) Response Accept (0x02) type 0x00 label 8 nosp 0
کنترل از راه دور AVRCP (AVRCP Remote Control)
نمایه AVRCP (نمایه کنترل از راه دور صوتی/تصویری) از L2CAP PSM 23 (کنترل) و PSM 27 (مرور) استفاده میکند. ابزار btmon فریمبندی AVCTP و PDUهای AVRCP را رمزگشایی میکند.
کنترل بلندی صدا:
< ACL Data TX: Handle 1 flags 0x00 dlen 17
Channel: 66 len 13 [PSM 23 mode Basic (0x00)] {chan 2}
AVCTP Control: Response: type 0x00 label 0 PID 0x110e
AV/C: Accepted: address 0x48 opcode 0x00
Subunit: Panel
Opcode: Vendor Dependent
Company ID: 0x001958
AVRCP: SetAbsoluteVolume pt Single len 0x0001
Volume: 50.39% (64/127)
وضعیت پخش:
AVRCP: GetPlayStatus pt Single len 0x0009 SongLength: 0x00038270 (230000 milliseconds) SongPosition: 0x00000000 (0 milliseconds) PlayStatus: 0x01 (PLAYING)
متاداده قطعه موسیقی (پاسخ GetElementAttributes):
AVRCP: GetElementAttributes pt Single len 0x0050 AttributeCount: 0x02 Attribute: 0x00000001 (Title) CharsetID: 0x006a (UTF-8) AttributeValueLength: 0x000c AttributeValue: My Song Name Attribute: 0x00000002 (Artist) CharsetID: 0x006a (UTF-8) AttributeValueLength: 0x000b AttributeValue: The Artist
دستورات عبوری Passthrough (پخش، مکث، رد کردن قطعه):
AVCTP Control: Command: type 0x00 label 1 PID 0x110e
AV/C: Control: address 0x48 opcode 0x7c
Subunit: Panel
Opcode: Passthrough
Operation: 0x44 (PLAY Pressed)
Length: 0x00
اعلانهای رویداد (تغییر میزان صدا، تغییر قطعه موسیقی):
AVRCP: RegisterNotification pt Single len 0x0005 EventID: 0x0d (EVENT_VOLUME_CHANGED) Volume: 50.39% (64/127)
خودکارسازی تحلیل A2DP (Automating A2DP Analysis)
شناسایی فعالیتهای A2DP:
grep -n "AVDTP:\|Media Codec:" output.txt
ردگیری تغییرات وضعیت AVDTP:
grep -n "AVDTP:.*Command\|AVDTP:.*Response" output.txt
بررسی مذاکره کدک (آنچه انتخاب شده است):
grep -n "Set Configuration\|Media Codec:" output.txt
بررسی برقراری جریان صوتی -- جستجو برای پذیرش Start که با دادههای رسانه دنبال میشود:
grep -n "AVDTP: Start\|PSM 25.*chan 1" output.txt
تشخیص عدم تطابق کدک -- جستجو برای رد درخواست Set Configuration:
grep -n "Response Reject\|Error code:" output.txt
ردگیری میزان صدا و پخش AVRCP:
grep -n "SetAbsoluteVolume\|Volume:\|GetPlayStatus\|PlayStatus:" output.txt
الگوی عیبیابی کامل A2DP:
- 1.
- یافتن Connection Request از نوع L2CAP برای PSM 25 -- تایید راهاندازی کانال AVDTP
- 2.
- یافتن پاسخ Discover -- نمایش نقاط پایانی موجود و اینکه آیا هر کدام در حال حاضر استفاده میشوند یا خیر
- 3.
- یافتن پاسخ Get All Capabilities -- بررسی همپوشانی پشتیبانی از کدکها
- 4.
- یافتن Set Configuration -- بررسی کدک و پارامترهای توافقشده
- 5.
- یافتن Open و Start -- تایید موفقیتآمیز بودن راهاندازی جریان
- 6.
- یافتن اتصال دوم L2CAP روی PSM 25 -- کانال انتقال چندرسانهای
- 7.
- در صورت بروز خطا، بررسی Response Reject به همراه کد خطا
- 8.
- در صورت قطع شدن صدا، جستجو برای Suspend یا Close یا بررسی قطع اتصال ACL
HFP: نمایه هندزفری (HFP: Hands-Free Profile)
پروفایل HFP دادههای صوتی مکالمه را از طریق اتصالات SCO/eSCO و کنترل تماس را از طریق RFCOMM منتقل میکند. ابزار btmon ساختار فریمهای RFCOMM و راهاندازی اتصال SCO/eSCO را رمزگشایی (Decode) میکند. دستورات AT (پروتکل کنترل HFP) بهصورت دامپ هگزادسیمال خام در فریمهای داده RFCOMM نمایش داده میشوند -- ابزار btmon ساختار نحوی (Syntax) دستورات AT را تجزیه نمیکند.
کشف SDP (SDP Discovery)
پروفایل HFP از SDP برای کشف رکورد سرویس هندزفری (Hands-Free) یا درگاه صوتی (Audio Gateway) در دستگاه راه دور و همچنین شماره کانال RFCOMM آن استفاده میکند:
< ACL Data TX: Handle 1 flags 0x00 dlen 25
Channel: 64 len 21 [PSM 1 mode Basic (0x00)] {chan 0}
SDP: Service Search Attribute Request (0x06) tid 1 len 16
Search pattern: [len 5]
Sequence (6) with 3 byte(s) [8 extra bits] len 5
UUID (3) with 2 byte(s) [0 extra bits] len 3
Handsfree Audio Gateway (0x111f)
Max record count: 65535
Attribute list: [len 5]
Sequence (6) with 3 byte(s) [8 extra bits] len 5
Unsigned Integer (1) with 4 byte(s) [0 extra bits] len 5
0x0000ffff
Continuation state: 0
پاسخ دریافتی شامل رکورد سرویس به همراه کانال RFCOMM است:
> ACL Data RX: Handle 1 flags 0x02 dlen 89
Channel: 64 len 85 [PSM 1 mode Basic (0x00)] {chan 0}
SDP: Service Search Attribute Response (0x07) tid 1 len 80
Attribute bytes: 77
Attribute list: [len 75] {position 0}
Attribute: Service Class ID List (0x0001) [len 2]
Handsfree Audio Gateway (0x111f)
Attribute: Protocol Descriptor List (0x0004) [len 2]
L2CAP (0x0100)
RFCOMM (0x0003)
Channel: 1
Attribute: Bluetooth Profile Descriptor List (0x0009) [len 2]
Handsfree (0x111e)
Version: 0x0108
Continuation state: 0
فیلدهای کلیدی برای استخراج:
- کلاس سرویس (Service Class) -- مقدار Handsfree (0x111e) برای نقش HF، و Handsfree Audio Gateway (0x111f) برای نقش AG
- کانال RFCOMM -- شماره کانال ذیل RFCOMM (0x0003) در فهرست توصیفکننده پروتکل (مانند کانال ۱)
- نسخه نمایه (Profile Version) -- ذیل فهرست توصیفکننده نمایه بلوتوث (مانند 0x0108 = HFP 1.8، 0x0109 = HFP 1.9)
برقراری اتصال RFCOMM (RFCOMM Connection Setup)
پروتکل RFCOMM روی L2CAP PSM 3 اجرا میشود. برقراری اتصال در چندین مرحله انجام میشود: نشست چندگانهساز (Multiplexer) روی DLCI 0، مذاکره پارامترها، و سپس کانال داده روی DLCI مقصد.
اتصال L2CAP برای RFCOMM:
< ACL Data TX: Handle 1 flags 0x00 dlen 12
L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 3 (0x0003)
Source CID: 65
> ACL Data RX: Handle 1 flags 0x02 dlen 16
L2CAP: Connection Response (0x03) ident 2 len 8
Destination CID: 65
Source CID: 65
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
SABM/UA روی DLCI 0 (نشست چندگانهساز):
< ACL Data TX: Handle 1 flags 0x00 dlen 12
Channel: 65 len 4 [PSM 3 mode Basic (0x00)] {chan 1}
RFCOMM: Set Async Balance Mode (SABM) (0x2f)
Address: 0x03 cr 1 dlci 0x00
Control: 0x3f poll/final 1
Length: 0
FCS: 0x1c
> ACL Data RX: Handle 1 flags 0x02 dlen 12
Channel: 65 len 4 [PSM 3 mode Basic (0x00)] {chan 1}
RFCOMM: Unnumbered Ack (UA) (0x63)
Address: 0x03 cr 1 dlci 0x00
Control: 0x73 poll/final 1
Length: 0
FCS: 0xd7
مذاکره پارامترها (Parameter Negotiation) (دستور MCC روی DLCI 0):
Channel: 65 len 14 [PSM 3 mode Basic (0x00)] {chan 1}
RFCOMM: Unnumbered Info with Header Check (UIH) (0xef)
Address: 0x03 cr 1 dlci 0x00
Control: 0xef poll/final 0
Length: 10
FCS: 0x70
MCC Message type: DLC Parameter Negotiation CMD (0x20)
Length: 8
dlci 2 frame_type 0 credit_flow 15 pri 7
ack_timer 0 frame_size 127 max_retrans 0 credits 7
مقدار DLCI در دستور PN کانال هدف را مشخص میکند. برای کانال RFCOMM شماره N، مقدار DLCI برابر است با N * 2 (یا بسته به نقش آغازگر، N * 2 + 1).
SABM/UA روی DLCI هدف (کانال داده):
Channel: 65 len 4 [PSM 3 mode Basic (0x00)] {chan 1}
RFCOMM: Set Async Balance Mode (SABM) (0x2f)
Address: 0x0b cr 1 dlci 0x02
Control: 0x3f poll/final 1
Length: 0
FCS: 0x59
Channel: 65 len 4 [PSM 3 mode Basic (0x00)] {chan 1}
RFCOMM: Unnumbered Ack (UA) (0x63)
Address: 0x0b cr 1 dlci 0x02
Control: 0x73 poll/final 1
Length: 0
FCS: 0x92
دستور وضعیت مودم (Modem Status Command) (اعلام آمادگی):
Channel: 65 len 8 [PSM 3 mode Basic (0x00)] {chan 1}
RFCOMM: Unnumbered Info with Header Check (UIH) (0xef)
Address: 0x03 cr 1 dlci 0x00
Control: 0xef poll/final 0
Length: 4
FCS: 0x70
MCC Message type: Modem Status Command CMD (0x38)
Length: 2
dlci 2
fc 0 rtc 1 rtr 1 ic 0 dv 1
تبادل دستورات AT (راهاندازی SLC) (AT Command Exchange (SLC Setup))
پروفایل HFP از دستورات AT بر بستر RFCOMM برای کنترل تماس و مذاکره ویژگیها استفاده میکند. ابزار btmon این موارد را بهصورت فریمهای RFCOMM UIH نشان میدهد که متن دستور AT در دامپ هگزادسیمال آن قابل مشاهده است.
دستور AT در فریم RFCOMM UIH:
Channel: 65 len 21 [PSM 3 mode Basic (0x00)] {chan 1}
RFCOMM: Unnumbered Info with Header Check (UIH) (0xef)
Address: 0x09 cr 0 dlci 0x02
Control: 0xff poll/final 1
Length: 14
FCS: 0x86
Credits: 1
41 54 2b 42 52 53 46 3d 32 30 35 35 0d AT+BRSF=2055.
متن دستور AT در ستون ASCII دامپ هگزادسیمال (سمت راست) خوانا است. توالی راهاندازی اتصال سطح سرویس (SLC) ویژگیها و قابلیتهای دستگاه را تبادل میکند:
- 1.
- AT+BRSF=<features> / +BRSF:<features> -- تبادل بیتماسک ویژگیهای پشتیبانیشده
- 2.
- AT+BAC=1,2 -- کدکهای موجود (در صورت پشتیبانی از مذاکره کدک). شناسههای کدک: 1 = CVSD، 2 = mSBC، 3 = LC3-SWB
- 3.
- AT+CIND=? / +CIND:(...) -- پرسوجوی نگاشت نشانگرها
- 4.
- AT+CIND? / +CIND:values -- مقادیر کنونی نشانگرها
- 5.
- AT+CMER=3,0,0,1 -- فعالسازی گزارشدهی وضعیت نشانگرها
- 6.
- AT+CHLD=? / +CHLD:(0,1,2,3,4) -- پشتیبانی از تماس سهطرفه
بیتهای کلیدی ویژگیهای HFP (از AT+BRSF):
| بیت | ویژگی HF | ویژگی AG |
| 0 | EC/NR | تماس سهطرفه |
| 1 | تماس سهطرفه | EC/NR |
| 2 | نمایش شماره تماسگیرنده (CLI) | تشخیص صدا |
| 3 | تشخیص صدا | صدای زنگ درونباندی |
| 4 | کنترل صدای راه دور | برچسب صوتی |
| 5 | وضعیت تماس پیشرفته | رد تماس |
| 6 | کنترل تماس پیشرفته | وضعیت تماس پیشرفته |
| 7 | مذاکره کدک | کنترل تماس پیشرفته |
| 8 | نشانگرهای HF | کدهای خطای گسترشیافته |
| 9 | eSCO S4 (T2) | مذاکره کدک |
| 11 | eSCO S4 (T2) |
راهاندازی اتصال کدک (Codec Connection Setup)
هنگامی که هر دو طرف از مذاکره کدک پشتیبانی میکنند (بیت ویژگی ۷ در HF و بیت ۹ در AG)، دستگاه AG قبل از برقراری پیوند صوتی یک کدک را انتخاب میکند. این فرآیند بهصورت دستورات AT در فریمهای RFCOMM UIH ظاهر میشود:
AG -> HF: +BCS:2 (select mSBC) HF -> AG: AT+BCS=2 (confirm mSBC) AG -> HF: OK
شناسههای کدک HFP (مورداستفاده در AT+BAC و AT+BCS):
| شناسه | کدک | توضیحات |
| 1 | CVSD | باند باریک (۸ کیلوهرتز)، اجباری |
| 2 | mSBC | گفتار با پهنای باند گسترده (۱۶ کیلوهرتز) |
| 3 | LC3-SWB | باند فوق گسترده (۳۲ کیلوهرتز)، HFP 1.9+ |
این شناسههای کدک در سطح HFP با شناسههای کدک HCI متفاوت هستند.
تنظیمات صدا (Voice Setting)
پیش از راهاندازی SCO/eSCO، میزبان تنظیمات صوتی را پیکربندی میکند. برای CVSD، فرمت کدگذاری روی هوا برابر با CVSD است؛ برای mSBC یا LC3-SWB، این مقدار باید روی دادههای شفاف (Transparent Data) تنظیم شود:
< HCI Command: Write Voice Setting (0x0c|0x0026) plen 2
Setting: 0x0063
Input Coding: Linear
Input Data Format: 2's complement
Input Sample Size: 16-bit
# of bits padding at MSB: 0
Air Coding Format: Transparent Data
برای CVSD:
< HCI Command: Write Voice Setting (0x0c|0x0026) plen 2
Setting: 0x0060
Input Coding: Linear
Input Data Format: 2's complement
Input Sample Size: 16-bit
# of bits padding at MSB: 0
Air Coding Format: CVSD
راهاندازی اتصال SCO/eSCO (SCO/eSCO Connection Setup)
پس از مذاکره کدک، میزبان یک اتصال همگام را برای دادههای صوتی مکالمه برقرار میکند.
برقراری اتصال همگام (Setup Synchronous Connection) (پایه):
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
Handle: 1
Transmit bandwidth: 8000
Receive bandwidth: 8000
Max latency: 13
Setting: 0x0063
Input Coding: Linear
Input Data Format: 2's complement
Input Sample Size: 16-bit
# of bits padding at MSB: 0
Air Coding Format: Transparent Data
Retransmission effort: Optimize for link quality (0x02)
Packet type: 0x0008
EV3 may be used
برقراری اتصال همگام بهبودیافته (Enhanced Setup Synchronous Connection) (آگاه از کدک):
< HCI Command: Enhanced Setup Synchronous Connection (0x01|0x003d) plen 59
Handle: 1
Transmit bandwidth: 8000
Receive bandwidth: 8000
Transmit Coding Format:
Codec: mSBC (0x05)
Receive Coding Format:
Codec: mSBC (0x05)
Transmit Codec Frame Size: 60
Receive Codec Frame Size: 60
Input Coding Format:
Codec: mSBC (0x05)
Output Coding Format:
Codec: mSBC (0x05)
Input Coded Data Size: 16
Output Coded Data Size: 16
Input PCM Data Format: 2's complement
Output PCM Data Format: 2's complement
Input PCM Sample Payload MSB Position: 0
Output PCM Sample Payload MSB Position: 0
Input Data Path: HCI
Output Data Path: HCI
Input Transport Unit Size: 60
Output Transport Unit Size: 60
Max latency: 13
Packet type: 0x0008
EV3 may be used
Retransmission effort: Optimize for link quality (0x02)
شناسههای کدک HCI که توسط btmon نمایش داده میشوند:
| شناسه | نام در btmon | کاربرد |
| 0x02 | CVSD | صدای باند باریک |
| 0x03 | Transparent | حالت دادههای شفاف (Transparent) |
| 0x04 | Linear PCM | ورودی/خروجی فشردهنشده PCM |
| 0x05 | mSBC | گفتار با پهنای باند گسترده (WBS) |
| 0x06 | LC3 | باند فوق گسترده (LC3-SWB) |
تکمیل اتصال همگام (Synchronous Connection Complete) (نتیجه):
> HCI Event: Synchronous Connection Complete (0x2c) plen 17
Status: Success (0x00)
Handle: 257
Address: 11:22:33:44:55:66 (OUI 11-22-33)
Link type: eSCO (0x02)
Transmission interval: 0x0c
Retransmission window: 0x06
RX packet length: 60
TX packet length: 60
Air mode: Transparent (0x03)
فیلدهای کلیدی:
- نوع پیوند (Link type) -- مقدار SCO (0x00) برای حالت سنتی، و eSCO (0x02) برای حالت بهبودیافته (مورداستفاده در mSBC و LC3-SWB)
- حالت روی هوا (Air mode) -- مقدار CVSD (0x02) برای باند باریک، و Transparent (0x03) برای mSBC یا LC3-SWB
- طول بسته RX/TX -- مقدار معمول ۶۰ بایت برای تنظیمات mSBC T2
بستههای داده SCO (SCO Data Packets)
پس از برقراری اتصال همگام، دادههای صوتی بهصورت بستههای داده SCO/eSCO جریان مییابند:
> BR-ESCO: Handle 257 flags 0x00 dlen 60 < BR-ESCO: Handle 257 flags 0x00 dlen 60
ابزار btmon بستهها را بر اساس نوع اتصال برقرارشده در Synchronous Connection Complete برچسبگذاری میکند:
- BR-SCO -- اتصال سنتی SCO
- BR-ESCO -- اتصال بهبودیافته SCO (شامل mSBC، LC3-SWB، یا eSCO CVSD)
بار داده (Payload) بستههای SCO بهطور پیشفرض نمایش داده نمیشود. برای مشاهده دامپ هگزادسیمال دادههای صوتی، فیلتر --show-sco-data مورد نیاز است.
خلاصه اتصالات بر اساس نوع کدک (Codec-Specific Connection Summary)
CVSD (باند باریک):
- شناسه کدک HFP: ۱
- کدک HCI: برابر با CVSD (0x02)
- تنظیمات صوتی: 0x0060 (قالب کدگذاری روی هوا: CVSD)
- حالت روی هوا: CVSD (0x02)
- نوع پیوند: SCO یا eSCO
- اندازه معمول بسته: ۴۸ بایت (HV3) یا ۶۰ بایت (EV3)
mSBC (گفتار با پهنای باند گسترده):
- شناسه کدک HFP: ۲
- کدک HCI: برابر با mSBC (0x05)
- تنظیمات صوتی: 0x0063 (قالب کدگذاری روی هوا: دادههای شفاف / Transparent Data)
- حالت روی هوا: Transparent (0x03)
- نوع پیوند: eSCO
- اندازه معمول بسته: ۶۰ بایت (EV3، تنظیمات T2)
LC3-SWB (باند فوق گسترده):
- شناسه کدک HFP: ۳
- کدک HCI: برابر با LC3 (0x06)
- تنظیمات صوتی: 0x0063 (قالب کدگذاری روی هوا: دادههای شفاف / Transparent Data)
- حالت روی هوا: Transparent (0x03)
- نوع پیوند: eSCO
- نکته: ابزار btmon عبارت LC3 را نمایش میدهد، نه LC3-SWB
خودکارسازی تحلیل HFP (Automating HFP Analysis)
شناسایی فعالیت HFP -- جستجو برای RFCOMM روی PSM 3:
grep -n "PSM: 3\|RFCOMM:" output.txt
خواندن دستورات AT -- جستجوی الگوهای دستورات AT در بخش ASCII دامپ هگز:
grep -n "AT+B\|AT+C\|+BRSF\|+CIND\|+CHLD\|+BCS" output.txt
بررسی مذاکره کدک -- جستجو برای BCS (انتخاب کدک بلوتوث):
grep -n "+BCS\|AT+BAC\|AT+BCS" output.txt
بررسی و تأیید راهاندازی SCO/eSCO:
grep -n "Setup Synchronous\|Enhanced Setup Synchronous\|Synchronous Connection Complete\|Write Voice Setting" output.txt
بررسی کدک صوتی -- تأیید حالت روی هوا و قالب کدگذاری:
grep -n "Air mode:\|Air Coding Format:\|Codec:" output.txt
تشخیص خطاهای SCO -- بررسی وضعیت Synchronous Connection Complete:
grep -n "Synchronous Connection Complete" output.txt
سپس خط بعدی را برای Status: بررسی کنید. خطاهای متداول:
- Connection Rejected due to Limited Resources (0x0d) -- کنترلر نمیتواند پهنای باند اختصاص دهد
- SCO Offset Rejected (0x2b) -- پارامترهای زمانبندی رد شدهاند
- SCO Interval Rejected (0x2c) -- پارامترهای بازه زمانی رد شدهاند
ردیابی وضعیت تماس -- جستجو برای بهروزرسانیهای نشانگر CIEV:
grep -n "+CIEV\|AT+CHUP\|ATD\|ATA\|AT+CLCC\|RING" output.txt
الگوی کامل عیبیابی HFP:
- 1.
- یافتن پرسوجوی SDP برای UUID 0x111e/0x111f -- تأیید کشف HFP
- 2.
- یافتن L2CAP Connection Request برای PSM 3 -- راهاندازی کانال RFCOMM
- 3.
- یافتن RFCOMM SABM/UA روی DLCI 0 و سپس DLCI مقصد -- چندگانهساز و کانال داده
- 4.
- یافتن AT+BRSF در دامپهای هگزادسیمال -- تبادل ویژگیها، بررسی بیت مذاکره کدک
- 5.
- یافتن AT+BAC در دامپهای هگزادسیمال -- کدکهای موجود گزارششده
- 6.
- یافتن +BCS/AT+BCS در دامپهای هگزادسیمال -- کدک انتخابشده برای صوت
- 7.
- یافتن Write Voice Setting -- تأیید تطابق قالب کدگذاری روی هوا با کدک
- 8.
- یافتن Setup Synchronous Connection یا نگارش Enhanced آن -- راهاندازی SCO
- 9.
- یافتن Synchronous Connection Complete -- بررسی Status، Link type و Air mode
- 10.
- یافتن بستههای BR-SCO یا BR-ESCO -- جریان یافتن دادههای صوتی
تبلیغ و پویش (ADVERTISING AND SCANNING)
ابزار btmon ساختارهای دادههای تبلیغ (advertising data) را بهطور خودکار رمزگشایی میکند. دادههای تبلیغ و پاسخ پویش (scan response) در رویدادهای گزارش تبلیغ HCI LE و در پارامترهای دستورات تبلیغ ظاهر میشوند.
گزارشهای تبلیغ (Advertising Reports)
هنگامی که کنترلر تبلیغات دریافتی را گزارش میکند:
> HCI Event: LE Meta Event (0x3e) plen 43 #120 [hci0] 0.500003
LE Extended Advertising Report (0x0d)
Event type: 0x0013
Props: 0x0013
Connectable
Scannable
Complete
Address type: Random (0x01)
Address: 00:11:22:33:44:55
Primary PHY: LE 1M
Secondary PHY: LE 2M
SID: 0x01
TX power: 0 dBm
RSSI: -55 dBm (0xc9)
Data length: 18
ساختارهای دادههای تبلیغ (AD) درون گزارش به صورت فیلدهای نوعدار رمزگشایی میشوند:
انواع متداول AD که btmon رمزگشایی میکند:
| نوع AD | نام | نمونه در خروجی btmon |
| 0x01 | Flags | Flags: 0x06 همراه با بیتهای رمزگشاییشده (LE General Discoverable، BR/EDR Not Supported) |
| 0x02/0x03 | Incomplete/Complete 16-bit UUIDs | 16-bit Service UUIDs (complete): 2 entries به دنبال آن فهرست UUIDها |
| 0x06/0x07 | Incomplete/Complete 128-bit UUIDs | 128-bit Service UUIDs (complete): 1 entry |
| 0x08/0x09 | Shortened/Complete Local Name | Name (complete): MyDevice |
| 0x0a | TX Power Level | TX power: 4 dBm |
| 0x16 | Service Data (16-bit UUID) | Service Data (UUID 0x184e): ... با رمزگشایی مختص پروتکل |
| 0xff | Manufacturer Specific Data | Company: Apple, Inc. (76) به دنبال دادههای هگزادسیمال |
نمونه گزارش تبلیغ معمولی:
> HCI Event: LE Meta Event (0x3e) plen 38 #120 [hci0] 0.500003
LE Extended Advertising Report (0x0d)
Address: 00:11:22:33:44:55
RSSI: -62 dBm (0xc2)
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Name (complete): LE-Audio-Left
16-bit Service UUIDs (complete): 3 entries
Published Audio Capabilities (0x1850)
Audio Stream Control (0x184e)
Common Audio (0x1853)
Service Data (UUID 0x1852): 01a2b3
Appearance: Earbud (0x0941)
تبلیغ گسترشیافته (Extended Advertising)
کنترلرهای مدرن از دستورات و رویدادهای تبلیغ گسترشیافته استفاده میکنند. توالی راهاندازی در btmon:
< HCI Command: LE Set Extended Adv Parameters (0x08|0x0036) plen 25 #50 [hci0] 0.100003
Handle: 0x01
Properties: 0x0000
Min advertising interval: 160.000 msec (0x0100)
Max advertising interval: 160.000 msec (0x0100)
Channel map: 37, 38, 39 (0x07)
Own address type: Random (0x01)
Peer address type: Public (0x00)
PHY: LE 1M, LE 2M
SID: 0x01
TX power: 7 dBm
< HCI Command: LE Set Extended Adv Data (0x08|0x0037) plen 35 #52 [hci0] 0.101003
Handle: 0x01
Operation: Complete extended advertising data (0x01)
Fragment preference: No fragmentation (0x01)
تبلیغ دورهای (صوت LE) (Periodic Advertising (LE Audio))
منابع پخش صوت LE از تبلیغ دورهای برای ارسال اعلانهای BASE حاوی پیکربندی کُدک (codec) استفاده میکنند:
> HCI Event: LE Meta Event (0x3e) plen 80 #200 [hci0] 0.500003
LE Periodic Advertising Report (0x0f)
Sync handle: 0x0001
TX power: 0 dBm
RSSI: -45 dBm
CTE Type: No CTE (0xff)
Data status: Complete (0x00)
Data length: 60
Service Data: Basic Audio Announcement (0x1851)
Presentation Delay: 40000 us
Number of Subgroups: 1
Codec: LC3 (0x06)
Sampling Frequency: 48000 Hz
Frame Duration: 10 ms
Frame Length: 120
خودکارسازی تحلیل تبلیغات (Automating Advertising Analysis)
یافتن همه گزارشهای تبلیغ (دستگاههای دیدهشده):
grep -n "Advertising Report\|Address:.*RSSI:" output.txt
استخراج نام دستگاهها:
grep -n "Name (complete):\|Name (short):" output.txt
یافتن دستگاههای LE Audio (از روی UUID سرویسها در تبلیغ):
grep -n "Audio Stream Control\|Published Audio Capabilities\|Common Audio\|Basic Audio Announcement\|Broadcast Audio" output.txt
ردیابی راهاندازی تبلیغ (پیکربندی تبلیغ توسط دستگاه محلی):
grep -n "Set Extended Adv\|Set Advertising\|Set Scan Response\|Adv Enable" output.txt
یافتن تبلیغ دورهای (پخش صوت):
grep -n "Periodic Advertising\|PA Sync\|PA Report\|Basic Audio Announcement\|Broadcast.*Announcement" output.txt
شناسایی دستگاهها بر اساس ظاهر (Appearance):
grep -n "Appearance:" output.txt
جریانهای پروتکل مدیریت (MGMT PROTOCOL FLOWS)
رابط مدیریت (MGMT) پروتکل ساختاریافته دستور/رویداد بین فضای کاربری (معمولاً bluetoothd) و زیرسیستم بلوتوث هسته (kernel) است. در خروجی btmon، ترافیک MGMT با پیشوند @ مشخص میشود و دیدگاهی در سطح بالاتر از HCI خام نسبت به پیکربندی آداپتور، کشف دستگاهها، جفتسازی و مدیریت اتصال فراهم میکند. این بخش جریانهای متداول پروتکل MGMT را همانگونه که از طریق btmon دیده میشوند، پوشش میدهد.
برای اصول پایه قالب خروجی MGMT (ساختار خطوط، Open/Close، پارامترها و رویدادها)، به زیربخش «ترافیک مدیریت (Management Traffic)» در بخش خواندن خروجی (READING THE OUTPUT) در بالا مراجعه کنید.
راهاندازی اولیه و تبادل نسخه (Initialization and Version Handshake)
هنگامی که bluetoothd شروع به کار میکند، یک سوکت مدیریت باز میکند و نسخه پروتکل و ویژگیهای پشتیبانیشده را از هسته استعلام مینماید. این دستتکانی (handshake) باید قبل از هرگونه عملیات کنترلر با موفقیت انجام شود:
@ MGMT Open: bluetoothd (privileged) version 1.23 {0x0001} 12:34:49.881936
@ MGMT Command: Read Management Ver.. (0x0001) plen 0 {0x0001} 12:34:49.882003
@ MGMT Event: Command Complete (0x0001) plen 6 {0x0001} 12:34:49.882010
Read Management Version Information (0x0001) plen 3
Status: Success (0x00)
Version: 1.23
@ MGMT Command: Read Management Sup.. (0x0002) plen 0 {0x0001} 12:34:49.882050
@ MGMT Event: Command Complete (0x0001) plen 58 {0x0001} 12:34:49.882055
Read Supported Commands (0x0002) plen 55
Status: Success (0x00)
Num of commands: 120
Num of events: 38
پس از بررسی نسخه، bluetoothd فهرست کنترلرها را میخواند و اطلاعات هر کنترلر را استعلام میکند:
@ MGMT Command: Read Controller Index List (0x0003) plen 0 {0x0001} 12:34:49.882100
@ MGMT Event: Command Complete (0x0001) plen 7 {0x0001} 12:34:49.882105
Read Controller Index List (0x0003) plen 4
Status: Success (0x00)
Num controllers: 1
Controller: hci0
@ MGMT Command: Read Controller Inf.. (0x0004) plen 0 {0x0001} [hci0] 12:34:49.882200
@ MGMT Event: Command Complete (0x0001) plen 283 {0x0001} [hci0] 12:34:49.882210
Read Controller Information (0x0004) plen 280
Status: Success (0x00)
Address: 00:11:22:33:44:55
Bluetooth version: 5.4
Manufacturer: Intel (2)
Supported settings: 0x003effff
Current settings: 0x00000080
نکات کلیدی برای بررسی در جریان راهاندازی اولیه:
- MGMT Open -- اتصال bluetoothd را تأیید میکند. در صورت عدم وجود، دیمن شروع به کار نکرده یا قبل از رسیدن به راهاندازی MGMT کرش کرده است.
- عدم تطابق نسخه (Version mismatch) -- اگر bluetoothd انتظار نسخه جدیدتری از MGMT را نسبت به آنچه هسته ارائه میدهد داشته باشد، ممکن است برخی ویژگیها در دسترس نباشند.
- Num controllers: 0 -- هیچ سختافزار بلوتوثی شناسایی نشده است. لاگهای dmesg را برای مشکلات درایور بررسی کنید.
- Current settings -- ماسک بیتی نشان میدهد چه مواردی در حال حاضر روی کنترلر فعال هستند (Powered، LE، BR/EDR، SSP و غیره).
پیکربندی آداپتور (Adapter Configuration)
پس از خواندن اطلاعات کنترلر، bluetoothd آداپتور را با مجموعهای از دستورات MGMT قبل از روشن کردن آن پیکربندی میکند. توالی دقیق به تنظیمات main.conf و قابلیتهای آداپتور بستگی دارد.
بارگذاری کلیدهای ذخیرهشده:
@ MGMT Command: Load Link Keys (0x0012) plen 3 {0x0001} [hci0] 12:34:50.001200
Debug keys: Disabled (0x00)
Key count: 0
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 12:34:50.001220
Load Link Keys (0x0012) plen 1
Status: Success (0x00)
@ MGMT Command: Load Long Term Keys (0x0013) plen 2 {0x0001} [hci0] 12:34:50.001300
Key count: 0
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 12:34:50.001315
Load Long Term Keys (0x0013) plen 1
Status: Success (0x00)
@ MGMT Command: Load Identity Resolving Keys (0x0030) plen 2 {0x0001} [hci0] 12:34:50.001400
Key count: 0
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 12:34:50.001415
Load Identity Resolving Keys (0x0030) plen 1
Status: Success (0x00)
هنگامی که دستگاههای پیوندخورده (bonded) وجود داشته باشند، مقدار Key count غیر صفر خواهد بود و btmon تکتک ورودیهای کلید را فهرست میکند. تعداد زیاد کلیدها میتواند نشاندهنده دستگاههای جفتشده متعدد باشد؛ این امر کاملاً طبیعی است.
تنظیم ویژگیهای آداپتور:
@ MGMT Command: Set Secure Connections (0x002d) plen 1 {0x0001} [hci0] 12:34:50.002100
Secure connections: Enabled (0x01)
@ MGMT Event: Command Complete (0x0001) plen 7 {0x0001} [hci0] 12:34:50.002120
Set Secure Connections (0x002d) plen 4
Status: Success (0x00)
Current settings: 0x004e0a81
@ MGMT Command: Set Bondable (0x0009) plen 1 {0x0001} [hci0] 12:34:50.002200
Bondable: Enabled (0x01)
@ MGMT Event: Command Complete (0x0001) plen 7 {0x0001} [hci0] 12:34:50.002220
Set Bondable (0x0009) plen 4
Status: Success (0x00)
Current settings: 0x004e0a91
روشن کردن (Powering on):
@ MGMT Command: Set Powered (0x0005) plen 1 {0x0001} [hci0] 12:35:04.033564
Powered: Enabled (0x01)
@ MGMT Event: Command Complete (0x0001) plen 7 {0x0001} [hci0] 12:35:04.114789
Set Powered (0x0005) plen 4
Status: Success (0x00)
Current settings: 0x004e0ac1
بین دستور Set Powered و پاسخ آن، btmon دستورات HCI ارسالی توسط هسته را برای مقداردهی اولیه رادیو نمایش میدهد (به «توالی راهاندازی اولیه HCI» مراجعه کنید).
کشف دستگاهها (Discovery)
کشف دستگاهها بهجای دستورات خام HCI از طریق MGMT آغاز میشود. bluetoothd (یا btmgmt) یک دستور Start Discovery ارسال میکند که انواع انتقال (transport) مورد نظر برای پویش را مشخص میسازد.
شروع کشف:
@ MGMT Command: Start Discovery (0x0023) plen 1 {0x0001} [hci0] 12:36:00.100200
Address type: 0x07
BR/EDR
LE Public
LE Random
@ MGMT Event: Command Complete (0x0001) plen 5 {0x0001} [hci0] 12:36:00.100500
Start Discovery (0x0023) plen 2
Status: Success (0x00)
Address type: 0x07
پس از این، btmon دستورات پویش سطح HCI صادرشده توسط هسته را نشان میدهد (LE Set Scan Parameters، LE Set Scan Enable و/یا Inquiry برای BR/EDR). دستگاههای کشفشده بهصورت رویدادهای MGMT ظاهر میشوند:
@ MGMT Event: Device Found (0x0012) plen 38 {0x0001} [hci0] 12:36:00.250003
LE Address: AA:BB:CC:DD:EE:FF (Random)
RSSI: -62
Flags: 0x0000
EIR Data:
Name (complete): My Device
TX power: 0
کشف سرویس از یک نسخه فیلترشده استفاده میکند:
@ MGMT Command: Start Service Discovery (0x003a) plen 19 {0x0001} [hci0] 12:36:10.100200
Address type: 0x06
LE Public
LE Random
RSSI threshold: -127
UUIDs: 1
UUID: Heart Rate (0x180d)
@ MGMT Event: Command Complete (0x0001) plen 5 {0x0001} [hci0] 12:36:10.100500
Start Service Discovery (0x003a) plen 2
Status: Success (0x00)
توقف کشف:
@ MGMT Command: Stop Discovery (0x0024) plen 1 {0x0001} [hci0] 12:36:15.200100
Address type: 0x07
@ MGMT Event: Command Complete (0x0001) plen 5 {0x0001} [hci0] 12:36:15.200400
Stop Discovery (0x0024) plen 2
Status: Success (0x00)
@ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 12:36:15.200500
Address type: 0x07
Discovery: Disabled (0x00)
مشکلات مربوط به کشف دستگاهها که باید بررسی شوند:
- Status: Busy (0x0a) در Start Discovery -- نشست کشف دیگری از قبل فعال است.
- Status: Not Powered (0x0f) -- آداپتور روشن نیست.
- Status: RFKilled (0x12) -- رادیو توسط rfkill مسدود شده است.
- عدم وجود رویدادهای Device Found -- ممکن است دستگاه دوردست در حال تبلیغ نباشد، یا فیلتر نوع آدرس اشتباه تنظیم شده باشد.
جفتسازی و پیوند از طریق MGMT (Pairing and Bonding via MGMT)
پروتکل MGMT یک رابط جفتسازی سطح بالا فراهم میکند. میزبان یک دستور Pair Device ارسال میکند؛ سپس هسته تبادلات SMP یا SSP را بر حسب مورد هماهنگ کرده و نتیجه را گزارش میدهد.
آغاز جفتسازی:
@ MGMT Command: Pair Device (0x0019) plen 8 {0x0001} [hci0] 12:37:00.500200
LE Address: AA:BB:CC:DD:EE:FF (Random)
Capability: KeyboardDisplay (0x04)
پس از این دستور، btmon تبادل زیربنایی SMP یا SSP را نمایش میدهد (برای جزئیات به «جریان جفتسازی SMP» و «توالی راهاندازی اولیه HCI» مراجعه کنید). ممکن است رویدادهای تعامل با کاربر ظاهر شوند:
@ MGMT Event: User Confirmation Request (0x000f) plen 12 {0x0001} [hci0] 12:37:01.200100
LE Address: AA:BB:CC:DD:EE:FF (Random)
Value: 123456
@ MGMT Command: User Confirmation Reply (0x001e) plen 6 {0x0001} [hci0] 12:37:03.800200
LE Address: AA:BB:CC:DD:EE:FF (Random)
@ MGMT Event: Command Complete (0x0001) plen 10 {0x0001} [hci0] 12:37:03.800350
User Confirmation Reply (0x001e) plen 7
Status: Success (0x00)
یا برای ورود کلید عبور (passkey):
@ MGMT Event: User Passkey Request (0x0010) plen 6 {0x0001} [hci0] 12:37:01.200100
LE Address: AA:BB:CC:DD:EE:FF (Random)
@ MGMT Command: User Passkey Reply (0x0020) plen 10 {0x0001} [hci0] 12:37:05.100200
LE Address: AA:BB:CC:DD:EE:FF (Random)
Passkey: 123456
موفقیت در جفتسازی:
@ MGMT Event: New Long Term Key (0x000a) plen 37 {0x0001} [hci0] 12:37:06.100200
Store hint: Yes (0x01)
LE Address: AA:BB:CC:DD:EE:FF (Random)
Key type: Authenticated P-256 (0x03)
Central: 0x00
Encryption size: 16
@ MGMT Event: New Identity Resolving Key (0x0018) plen 30 {0x0001} [hci0] 12:37:06.100300
Store hint: Yes (0x01)
Random address: AA:BB:CC:DD:EE:FF
LE Address: 11:22:33:44:55:66 (Public)
Key: 00112233445566778899aabbccddeeff
@ MGMT Event: Command Complete (0x0001) plen 10 {0x0001} [hci0] 12:37:06.100500
Pair Device (0x0019) plen 7
Status: Success (0x00)
LE Address: AA:BB:CC:DD:EE:FF (Random)
رویدادهای کلیدی برای بررسی پس از جفتسازی:
- New Long Term Key با Store hint: Yes -- هسته به فضای کاربری اعلام میکند که این کلید را برای اتصالات مجدد در آینده ذخیره کند.
- New Identity Resolving Key -- آدرس واقعی دستگاه را در پشت یک آدرس خصوصی قابل تفکیک (RPA) آشکار میسازد. این مورد برای تفکیک آدرس در اتصال مجدد ضروری است.
- Key type -- مقدار Authenticated P-256 نشاندهنده اتصالات امن (Secure Connections) همراه با حفاظت MITM است. Unauthenticated P-256 به معنی Just Works SC است. Authenticated (بدون P-256) به معنی حالت سنتی (Legacy) با حفاظت MITM است.
شکست در جفتسازی:
@ MGMT Event: Command Complete (0x0001) plen 10 {0x0001} [hci0] 12:37:06.100500
Pair Device (0x0019) plen 7
Status: Authentication Failed (0x05)
LE Address: AA:BB:CC:DD:EE:FF (Random)
کدهای خطای جفتسازی MGMT:
| کد | وضعیت | مفهوم تشخیصی |
| 0x03 | Failed | شکست عمومی؛ خطاهای SMP یا HCI ماقبل این را بررسی کنید |
| 0x04 | Connect Failed | عدم امکان برقراری اتصال پیش از جفتسازی |
| 0x05 | Authentication Failed | احراز هویت SMP یا SSP ناموفق بود؛ دلیل SMP Pairing Failed یا رویداد HCI Authentication Failure را بررسی کنید |
| 0x08 | Timeout | پایان مهلت زمانی جفتسازی؛ ممکن است دستگاه دوردست از برد خارج شده باشد |
| 0x0b | Rejected | دستگاه دوردست درخواست جفتسازی را رد کرد |
| 0x0d | Invalid Parameters | نوع آدرس یا مقدار قابلیت (capability) نامعتبر در دستور Pair Device |
اتصال و قطع اتصال دستگاه (Device Connection and Disconnection)
پروتکل MGMT رویدادهای چرخه حیات اتصال را گزارش میکند که مکمل رویدادهای سطح HCI نشاندادهشده در سایر بخشهای لاگ هستند.
اتصال دستگاه:
@ MGMT Event: Device Connected (0x000b) plen 13 {0x0001} [hci0] 12:36:18.974319
LE Address: AA:BB:CC:DD:EE:FF (Random)
Flags: 0x0000
EIR Data Length: 0
این رویداد پس از رویداد HCI به نام LE (Enhanced) Connection Complete رخ میدهد. این رویداد به فضای کاربری اعلام میکند که یک اتصال جدید آماده است.
قطع اتصال دستگاه:
@ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 12:38:20.500200
LE Address: AA:BB:CC:DD:EE:FF (Random)
Reason: Connection timeout (0x01)
دلایل قطع اتصال گزارششده توسط MGMT:
| کد | دلیل | مفهوم تشخیصی |
| 0x00 | Unspecified | دلیلی ارائه نشده است؛ معمولاً قطع اتصال محلی است |
| 0x01 | Connection timeout | مهلت نظارت بر پیوند (link supervision timeout) به پایان رسیده است؛ ممکن است دستگاه از برد خارج شده باشد |
| 0x02 | Connection terminated by local host | سمت محلی قطع اتصال را آغاز کرده است |
| 0x03 | Connection terminated by remote host | دستگاه دوردست قطع اتصال را آغاز کرده است |
دستور Unpair Device کلیدهای ذخیرهشده را حذف کرده و در صورت تمایل اتصال را قطع میکند:
@ MGMT Command: Unpair Device (0x001a) plen 7 {0x0001} [hci0] 12:39:00.100200
LE Address: AA:BB:CC:DD:EE:FF (Random)
Disconnect: Enabled (0x01)
@ MGMT Event: Command Complete (0x0001) plen 10 {0x0001} [hci0] 12:39:00.100500
Unpair Device (0x001a) plen 7
Status: Success (0x00)
تبلیغ از طریق MGMT (Advertising via MGMT)
سامانه BlueZ مدرن، تبلیغ را بهجای ارسال مستقیم دستورات تبلیغ HCI LE، از طریق دستورات MGMT پیکربندی میکند. این رویکرد زیرساختی چندکاربره (multi-client) برای تبلیغ فراهم میسازد.
افزودن تبلیغ:
@ MGMT Command: Add Advertising (0x003e) plen 22 {0x0001} [hci0] 12:40:00.100200
Instance: 1
Flags: 0x0006
The connectable flag will be managed
The limited discoverable flag will be managed
Duration: 0
Timeout: 0
Advertising data length: 6
Scan response length: 0
@ MGMT Event: Command Complete (0x0001) plen 5 {0x0001} [hci0] 12:40:00.100500
Add Advertising (0x003e) plen 2
Status: Success (0x00)
Instance: 1
حذف تبلیغ:
@ MGMT Command: Remove Advertising (0x003f) plen 1 {0x0001} [hci0] 12:41:00.100200
Instance: 1
@ MGMT Event: Command Complete (0x0001) plen 5 {0x0001} [hci0] 12:41:00.100500
Remove Advertising (0x003f) plen 2
Status: Success (0x00)
Instance: 1
برای دستورات تبلیغ سطح HCI که ناشی از این عملیاتهای MGMT هستند، به «تبلیغ و پویش (ADVERTISING AND SCANNING)» مراجعه کنید.
تشخیص خطا (Error Diagnosis)
رویدادهای MGMT Command Status و Command Complete حامل کدهای خطایی هستند که با کدهای خطای HCI تفاوت دارند. هنگام تشخیص خرابیها و خطاها، هر دو لایه را بررسی کنید.
MGMT error in Command Complete:
@ MGMT Event: Command Complete (0x0001) plen 4 {0x0001} [hci0] 12:42:00.100200
Set Powered (0x0005) plen 1
Status: RFKilled (0x12)
MGMT Command Status (پذیرش یا رد دستور ناهمگام / asynchronous):
@ MGMT Event: Command Status (0x0002) plen 3 {0x0001} [hci0] 12:42:01.100200
Start Discovery (0x0023) plen 0
Status: Busy (0x0a)
کدهای خطای MGMT:
| کد | وضعیت | مفهوم تشخیصی |
| 0x00 | Success | دستور با موفقیت انجام شد |
| 0x01 | Unknown Command | هسته دستور را شناسایی نمیکند؛ ممکن است نسخه MGMT خیلی قدیمی باشد |
| 0x02 | Not Connected | عملیات نیازمند یک اتصال فعال است که وجود ندارد |
| 0x03 | Failed | شکست عمومی؛ رویدادهای HCI را برای علت اصلی بررسی کنید |
| 0x04 | Connect Failed | تلاش برای اتصال در سطح HCI ناموفق بود |
| 0x05 | Authentication Failed | فرآیند جفتسازی یا احراز هویت با شکست مواجه شد |
| 0x06 | Not Paired | عملیات نیازمند یک پیوند (bond) موجود است؛ دستگاه جفت نشده است |
| 0x07 | No Resources | منابع هسته به پایان رسیده است (حافظه، هندلها و غیره) |
| 0x08 | Timeout | مهلت زمانی عملیات به پایان رسید |
| 0x09 | Already Connected | اتصال با دستگاه مقصد از قبل برقرار است |
| 0x0a | Busy | عملیات دیگری در حال انجام است (مثلاً کشف در حال اجرا است) |
| 0x0b | Rejected | عملیات توسط دستگاه دوردست یا خطمشیها (policy) رد شد |
| 0x0c | Not Supported | ویژگی توسط این کنترلر یا نسخه هسته پشتیبانی نمیشود |
| 0x0d | Invalid Parameters | پارامترهای نامعتبر در دستور |
| 0x0e | Disconnected | اتصال در حین انجام عملیات قطع شد |
| 0x0f | Not Powered | کنترلر روشن نیست؛ ابتدا Set Powered را فراخوانی کنید |
| 0x10 | Cancelled | عملیات توسط کاربر یا دستور دیگری لغو شد |
| 0x11 | Invalid Index | شاخص کنترلر وجود ندارد |
| 0x12 | RFKilled | رادیو توسط rfkill غیرفعال شده است؛ با rfkill unblock bluetooth رفع انسداد کنید |
| 0x13 | Already Paired | دستگاه از قبل جفت شده است؛ در صورت نیاز به جفتسازی مجدد، ابتدا unpair کنید |
| 0x14 | Permission Denied | فرایند فاقد امتیازات لازم است (CAP_NET_ADMIN) |
ارتباط دادن خطاهای MGMT و HCI: هنگامی که MGMT خطای Failed (0x03) یا Authentication Failed (0x05) را گزارش میکند، رویدادهای HCI بلافاصله قبل از پاسخ MGMT را بررسی کنید. خطای سطح HCI (مانند Authentication Failure (0x05)، Connection Timeout (0x08)) علت دقیق سختافزاری را مشخص میکند.
خودکارسازی تحلیل MGMT (Automating MGMT Analysis)
فهرست کردن تمام دستورات و رویدادهای MGMT:
grep -n "@ MGMT" output.txt
یافتن خطاهای MGMT (وضعیتهای غیر صفر):
grep -n "@ MGMT" output.txt | grep -v "Status: Success"
ردیابی تغییرات وضعیت برق آداپتور:
grep -n "Set Powered\|RFKilled\|Not Powered" output.txt
یافتن تمام فعالیتهای کشف دستگاهها:
grep -n "Start Discovery\|Stop Discovery\|Device Found\|Discovering" output.txt
یافتن فعالیتهای جفتسازی از طریق MGMT:
grep -n "Pair Device\|User Confirmation\|User Passkey\|New Long Term Key\|New Identity Resolving Key\|Authentication Failed" output.txt
یافتن رویدادهای چرخه حیات اتصال:
grep -n "Device Connected\|Device Disconnected\|Unpair Device" output.txt
شناسایی کلاینتهای فعال MGMT:
grep -n "@ MGMT Open\|@ MGMT Close" output.txt
الگوی کامل تشخیص MGMT:
- 1.
- یافتن MGMT Open -- اتصال bluetoothd را تأیید کنید و شناسه سوکت را یادداشت نمایید
- 2.
- بررسی Read Controller Information -- آدرس، نسخه و تنظیمات فعلی را بررسی کنید
- 3.
- یافتن Set Powered -- تأیید کنید که آداپتور با موفقیت روشن شده است
- 4.
- جستجو برای کدهای وضعیت غیر Success -- این کدها نشاندهنده خرابی و خطا هستند
- 5.
- برای مشکلات جفتسازی، Pair Device را پیدا کرده و تا پاسخ Command Complete مربوط به آن را ردیابی کنید
- 6.
- برای مشکلات اتصال، Device Connected/Device Disconnected را پیدا کرده و دلیل قطع اتصال را بررسی نمایید
مثالها (EXAMPLES)
ضبط ردپاها از hci0 در پرونده hcidump.log (Capture the traces from hci0 to hcidump.log file)
$ btmon -i hci0 -w hcidump.log
باز کردن پرونده ردپا (Open the trace file)
$ btmon -r hcidump.log
باز کردن پرونده ردپا با برچسبهای زمانی ساعت دیواری (Open the trace file with wall-clock timestamps)
$ btmon -t -r hcidump.log
باز کردن پرونده ردپا با تاریخ و زمان کامل (Open the trace file with full date and time)
$ btmon -T -r hcidump.log
تحلیل خودکار ردپای بستهها (AUTOMATED TRACE ANALYSIS)
این بخش راهنماییهایی را برای تحلیل برنامهنویسیشده یا با کمک هوش مصنوعی از ردپای بستههای btmon ارائه میدهد. هر موضوع به بخش تفصیلی مربوط به پروتکل در بخشهای پیشین این سند ارجاع دارد.
گردش کار توصیهشده (Recommended Workflow)
- 1.
- دریافت یک نمای کلی: با btmon -a <file> شروع کنید تا تعداد بستهها، هندلهای اتصال، نشانیهای دستگاهها و حجم ترافیک را مشاهده نمایید.
- 2.
- رمزگشایی همراه با برچسبهای زمانی: از btmon -t -r <file> > output.txt برای ایجاد یک پرونده متنی حاوی برچسبهای زمانی ساعت دیواری جهت تحلیل استفاده کنید.
- 3.
- شناسایی اتصالها: رویدادهای برقراری اتصال را برای ایجاد نگاشت هندل به نشانی جستجو کنید:
grep -n "Connection Complete\|Enhanced Connection Complete\|CIS Established" output.txt
- 4.
- ردیابی قطع اتصالها: رویدادهای قطع اتصال و دلایل آنها را جستجو کنید:
grep -n "Disconnect Complete" output.txt
سپس خطوط پس از هر تطابق را برای فیلد Reason: بررسی کنید. برای تفسیر به بخش «کدهای خطا و دلایل قطع اتصال HCI» (HCI ERROR AND DISCONNECT REASON CODES) مراجعه نمایید.
- 5.
- بررسی جفتسازی/امنیت: به دنبال فعالیتهای پروتکل SMP بگردید (به بخش «گردش کار جفتسازی SMP» (SMP PAIRING FLOW) مراجعه کنید):
grep -n "Pairing Request\|Pairing Response\|Pairing Failed\|Encryption Change" output.txt
- 6.
- شناسایی LE Audio: فعالیتهای مربوط به ASCS و CIS را جستجو کنید (به بخش «گردش پروتکل LE AUDIO» (LE AUDIO PROTOCOL FLOW) مراجعه کنید):
grep -n "ASE Control Point\|CIG Parameters\|Create Connected Isochronous\|CIS Established\|Setup ISO Data Path" output.txt
- 7.
- بررسی وجود خطاها: در تمام لایههای پروتکل به دنبال خطا بگردید (به بخش «کدهای خطای پروتکل» (PROTOCOL ERROR CODES) مراجعه کنید):
# HCI-level errors grep -n "Status:" output.txt | grep -v "Success" # ATT-level errors grep -n "Error Response" output.txt # SMP failures grep -n "Pairing Failed" output.txt # L2CAP rejections grep -n "Connection refused" output.txt
- 8.
- استخراج اکتشاف GATT: ترافیک مربوط به اکتشاف سرویس/مشخصه در GATT را فیلتر کنید (به بخش «بازسازی پایگاهداده GATT از ردپاهای SNOOP» (RECONSTRUCTING A GATT DATABASE FROM SNOOP TRACES) مراجعه کنید):
# Find all service discovery responses grep -n "Read By Group Type Response\|Attribute group list\|Handle range.*UUID" output.txt # Find all characteristic discovery responses grep -n "Read By Type Response\|Properties:\|Value Handle:\|Value UUID:" output.txt # Find all descriptor discovery responses grep -n "Find Information Response\|Format:\|Handle:.*UUID:" output.txt # Find targeted service searches grep -n "Find By Type Value" output.txt
- 9.
- بررسی کانالهای L2CAP: نحوه استفاده از پروتکل و مشکلات کانال را شناسایی کنید (به بخش «ردیابی کانال L2CAP» (L2CAP CHANNEL TRACKING) مراجعه کنید):
grep -n "PSM:\|Connection Request\|Connection Response\|Parameter Update" output.txt
- 10.
- بررسی تبلیغ (Advertising): ببینید چه دستگاههایی قابل مشاهده هستند و چه مواردی را تبلیغ میکنند (به بخش «تبلیغ و اسکن» (ADVERTISING AND SCANNING) مراجعه کنید):
grep -n "Advertising Report\|Name (complete):\|Appearance:" output.txt
الگوهای کلیدی برای چرخه حیات اتصال (Key Patterns for Connection Lifecycle)
چرخه حیات کامل یک اتصال LE ACL در ردپای بستهها از الگوی زیر پیروی میکند:
- 1.
- LE Enhanced Connection Complete -- اتصال برقرار شد، مقدار Handle و نشانی Peer را یادداشت کنید.
- 2.
- LE Connection Update Complete -- پارامترهای اتصال تغییر کرد (ممکن است صفر یا چند بار رخ دهد).
- 3.
- Encryption Change -- پیوند رمزگذاری شد (ممکن است الگوریتم رمزگذاری را نمایش دهد). برای تبادل اطلاعات SMP که پیش از این رخ میدهد، به بخش «گردش کار جفتسازی SMP» (SMP PAIRING FLOW) مراجعه کنید.
- 4.
- دادههای ACL با ATT/SMP/L2CAP -- اکتشاف سرویس و تبادل داده. برای GATT به بخش «بازسازی پایگاهداده GATT از ردپاهای SNOOP» (RECONSTRUCTING A GATT DATABASE FROM SNOOP TRACES)، برای راهاندازی کانال به «ردیابی کانال L2CAP» (L2CAP CHANNEL TRACKING) و برای تفسیر خطا به «کدهای خطای پروتکل» (PROTOCOL ERROR CODES) مراجعه نمایید.
- 5.
- Disconnect Complete -- اتصال پایان یافت، فیلد Reason را بررسی کنید. برای کدهای دلیل، به بخش «کدهای خطا و دلایل قطع اتصال HCI» (HCI ERROR AND DISCONNECT REASON CODES) مراجعه نمایید.
برای اتصالهای LE Audio، مراحل اضافی بین گام ۳ و ۵ ظاهر میشوند (برای جزئیات کامل به بخش «گردش پروتکل LE AUDIO» (LE AUDIO PROTOCOL FLOW) مراجعه کنید):
- عملیات ATT روی مشخصههای PACS/ASCS (مذاکره کدک صوتی)
- دستور و پاسخ LE Set CIG Parameters
- دستور LE Create CIS
- رویداد LE CIS Established (هندل CIS را یادداشت کنید)
- دستور LE Setup ISO Data Path
- دادههای ISO Data TX/RX (جریانسازی صوتی)
- Disconnect Complete روی هندل CIS (پایان یافتن جریان)
- دستور LE Remove CIG (گروه حذف شد)
سناریوهای رایج اشکالزدایی (Common Debugging Scenarios)
تشخیص شکست جفتسازی:
- 1.
- دستور Pairing Request را پیدا کنید -- قابلیتهای IO و الزامات احراز اصالت را یادداشت کنید.
- 2.
- پاسخ Pairing Response را پیدا کنید -- برای تعیین مدل پیوستگی، آنها را با یکدیگر مقایسه کنید.
- 3.
- اگر Pairing Failed نمایش داده شد، کد دلیل، نوع شکست را مشخص میکند (به بخش «گردش کار جفتسازی SMP» (SMP PAIRING FLOW) مراجعه کنید).
- 4.
- اگر Encryption Change وضعیت Status: Success را نشان داد، جفتسازی با موفقیت انجام شده است.
- 5.
- اگر هنگام اتصال مجدد هیچ ترافیک SMP وجود نداشت اما Encryption Change شکست خورد، پیوند پیوندیافته (bond) در یکی از طرفین از بین رفته است.
تشخیص خرابی در جریانسازی صدا (به بخش «گردش پروتکل LE AUDIO» (LE AUDIO PROTOCOL FLOW) مراجعه کنید):
- 1.
- خواندنهای PACS را بررسی کنید -- آیا هر دو دستگاه از کدکهای سازگار پشتیبانی میکنند؟
- 2.
- گزینه ASE Control Point Config Codec را بررسی کنید -- آیا پذیرفته شد؟
- 3.
- اعلانهای وضعیت ASE را بررسی کنید -- آیا ASE به وضعیت Streaming رسید؟
- 4.
- رویداد CIS Established را بررسی کنید -- آیا مقدار Status برابر با Success بود؟
- 5.
- دستور Setup ISO Data Path را بررسی کنید -- آیا پیکربندی شده بود؟
- 6.
- بستههای داده ISO Data را بررسی کنید -- آیا صدا در عمل در حال جریان است؟
رد شدن عملیات GATT (به بخش «کدهای خطای پروتکل» (PROTOCOL ERROR CODES) مراجعه کنید):
- 1.
- پاسخ Error Response را پیدا کنید -- کد خطا را یادداشت نمایید.
- 2.
- خطای Insufficient Encryption (0x0f) → انتظار میرود به دنبال آن LE Start Encryption اجرا شود.
- 3.
- خطای Authentication Insufficient (0x05) → انتظار میرود به دنبال آن جفتسازی SMP انجام شود.
- 4.
- پس از برقراری امنیت، عملیات ATT باید مجدداً تلاش شود.
شکست در مذاکره پارامترهای اتصال:
- 1.
- درخواست Connection Parameter Update Request را پیدا کنید (در سطح L2CAP).
- 2.
- پاسخ (Response) را بررسی کنید -- مقدار rejected به این معنی است که دستگاه مرکزی آن را رد کرده است.
- 3.
- همچنین میتوانید رویداد LE Connection Update Complete را پیدا کنید (در سطح HCI).
- 4.
- وضعیت (Status) را بررسی کنید -- مقدار غیرصفر به معنای رد بهروزرسانی توسط کنترلکننده است.
رویدادهای مختص سازنده (Vendor-Specific Events)
رویدادهای HCI مختص سازنده (کد رویداد 0xFF) حاوی دادههای تشخیصی شرکت سازنده کنترلکننده هستند. برنامه btmon برخی از رویدادهای مربوط به سازندگان شناختهشده (Intel، Broadcom و غیره) را رمزگشایی میکند، اما بسیاری از زیررویدادها بهصورت Unknown همراه با دادههای خام هگزادسیمال نمایش داده میشوند. این وضعیت طبیعی و مورد انتظار است و عموماً بدون مستندات سازنده قابل اقدام نیست.
کنترلکنندههای Intel رویدادهای تلهمتری پیشرفتهای (زیررویداد 0x8780) صادر میکنند که معیارهای کیفیت اتصال، شمارندههای خطا و وضعیت سیستمعامل (firmware) را در بر میگیرد. رمزگشایی جزئی در monitor/intel.c در دسترس است.
منابع (RESOURCES)
گزارش اشکال (REPORTING BUGS)
<linux-bluetooth@vger.kernel.org>
همچنین ببینید (SEE ALSO)
btsnoop(7)
نویسندگان (AUTHORS)
Marcel Holtmann <marcel@holtmann.org>, Tedd Ho-Jeong An <tedd.an@intel.com>
حق نشر (COPYRIGHT)
استفاده آزاد از این نرمافزار تحت شرایط مجوز عمومی همگانی کمتر گنو (LGPL) مجاز است.
| April 2021 | BlueZ |