84 lines
7.3 KiB
Plaintext
84 lines
7.3 KiB
Plaintext
BLE Windows: идентичность обнаружения и подключаемый endpoint
|
||
==========================================================
|
||
|
||
Наблюдение 31.10.2026
|
||
--------------------
|
||
SM02:25:13, request2: node1588291579282de3, endpoint6B:BF:97:68:12:7C,
|
||
seen_connectable=false, service_uuid_seen=false. Через15s operation timeout,
|
||
STATE_CONNECTED/MTU/discovery/передачи INVITE не было. Windows chatgui.log:
|
||
publisher Started, GATT service Started, ни одного входящего GATT, shutdown links=0.
|
||
Часы Windows/SM различаются примерно на минуту; сравнивать их как одну шкалу нельзя.
|
||
Совпадение peer/endpoint и фаз надёжнее абсолютного timestamp.
|
||
|
||
Свежий HCI /tmp/utun-sm-win-live.btsnoop: тот же6B:BF:97:68:12:7C передаёт
|
||
ADV_SCAN_IND(0x0012, scannable, не connectable), company65535, данные
|
||
5643041588291579282de36a656b612d7768. На нём чередуется и company6 Microsoft.
|
||
В прежнем HCI тот же node передавался с другого RPA77:AD:98:E7:C2:DC также
|
||
как ADV_SCAN_IND. Ошибка воспроизводится с новым адресом и актуальной диагностикой.
|
||
|
||
Несогласованность
|
||
----------------
|
||
WinRT запускает отдельные BluetoothLEAdvertisementPublisher для manufacturer и
|
||
GattServiceProvider для connectable GATT. Started обоих API не связывает адрес
|
||
manufacturer-пакета с подключаемым сервером. Android выбирает адрес из manufacturer,
|
||
а ble_etcp принимает его как пригодный endpoint. Увеличение timeout/MTU/priority
|
||
не делает ADV_SCAN_IND подключаемым. Простое удаление таких объявлений из таблицы
|
||
лишь скрывает Windows и тоже не обеспечивает вступление/приглашения.
|
||
|
||
Требование к исправлению
|
||
-----------------------
|
||
Связь node_id → endpoint должна происходить по подключаемому объявлению самого
|
||
сервиса. Не угадывать public/random адрес, не сопоставлять разные RPA по имени/RSSI.
|
||
Не переносить доверие из объявления в ETCP/JOIN: pubkey и CCM проверяются как прежде.
|
||
Обнаружение, показ имени и возможность подключения — разные свойства записи.
|
||
Неподключаемый маяк не должен заменять уже найденный подключаемый endpoint.
|
||
|
||
Варианты
|
||
--------
|
||
1. Идентичность в ServiceData того же GattServiceProvider, который принимает GATT.
|
||
В legacy payload с128-bit UUID помещаются версия+node_id, имя отдельно.
|
||
Подходит лишь с Windows18362/1903; установленная17763 не имеет ServiceData API.
|
||
Справка Microsoft:
|
||
https://learn.microsoft.com/en-us/uwp/api/windows.devices.bluetooth.genericattributeprofile.gattserviceprovideradvertisingparameters.servicedata
|
||
|
||
2. Рекомендуемый для17763: UUID самого сервиса содержит node_id и фиксированный
|
||
префикс/версию семейства протокола. Такой UUID поддерживает существующий GATT API,
|
||
помещается в legacy advertising и непосредственно связывает обнаружение с сервером.
|
||
Имя может показываться из доступных метаданных, иначе используется node_id, как сейчас.
|
||
Клиент выбирает сервис по ожидаемому node_id; server создаёт свой UUID из локального ID.
|
||
Нужен один общий codec UUID и согласованное изменение BlueZ/WinRT/Android и стендов.
|
||
Это изменение discovery-протокола всех платформ, а не исправление одного callback.
|
||
|
||
Перед реализацией варианта2 нужно согласовать таблицу настроек advertise/incoming:
|
||
выключенное объявление идентичности не должно молча раскрывать node_id через UUID;
|
||
broadcast-only не должен превращаться в разрешение подключений. Настройка получения
|
||
INVITE и допуск ETCP также остаются отдельными проверками. Нужен явный контракт
|
||
для всех сочетаний, включая уже известный адрес и UUID при выключенном discovery.
|
||
|
||
Проверка
|
||
--------
|
||
Общий codec UUID: все64 бита node_id, версия/семейство, GUID byte order C/WinRT,
|
||
отказ на чужой UUID. Discovery: два разных адреса beacon/service, чужой узел,
|
||
смена RPA, старый endpoint и флаги настроек. Транспорт: прежние MTU/INVITE/JOIN tests.
|
||
Физически: в HCI подключаемое объявление с идентичностью Windows, на SM соединение
|
||
с тем же адресом, Windows subscriptions/HELLO, подтверждение INVITE status1 и JOIN.
|
||
Пока изменена только диагностика Android; функциональная адресация не изменялась.
|
||
|
||
Рабочее решение: GATT-профиль,31.10.2026
|
||
--------------------------------------
|
||
После проб dual advertising сохраняется один GattServiceProvider advertisement.
|
||
NODE_NAME/NODE_ID добавлены как Read характеристики с постоянными UUID9025/9026.
|
||
Имена читаются краткими GATT-подключениями после discovery; полного ника в advertising нет.
|
||
Переключение рекламы и второй publisher в рабочую реализацию не добавляются.
|
||
Актуальный контракт и команды новой пробы — doc/ble_transport.txt.
|
||
|
||
Физическая проверка31.10.2026,14:37:07..08
|
||
---------------------------------------
|
||
Windows запущена из /home/user/utun-gatt-profile-probe-windows.zip, режим listen.
|
||
Linux ble_profile_probe profile180 получил живое объявление с RPA61:D6:B7:C0:60:04
|
||
и node56434455414c0001. Backend переиспользовал существующий ACL78:C0:C3:B8:55:30
|
||
того же узла, прочитал NODE_ID и NODE_NAME: «VibeChat: полное имя устройства»,50 байт UTF-8.
|
||
Собственный профильный handle закрыт штатно; PROFILE_PROBE_PASS без CCC/HELLO/ETCP.
|
||
Лог клиента: /tmp/utun-gatt-profile-windows-linux-pass.log.
|
||
Проверка подтверждает discovery и Read-характеристики Windows; порядок DATA этой пробой не проверяется.
|