一句话先答不是名字丢了——名字的获取有一条两级降级机制兜底最终的空名字是小概率的漏网之鱼实测 5% 左右而漏网的根源是补查失败一次就永久放弃。做蓝牙的兄弟大概都见过这个场景手机开蓝牙一扫列表里大部分设备都有名字——小米电视、JBL Flip 6、XXX耳机可总有那么一两条地址、信号强度都在名字那栏空着。我们项目里就是这么撞上的实测某个海思平台扫描结果里 name 为空的比例稳定在5% 左右。就是这个不起眼的 5%逼着我们把经典蓝牙的发现机制从头扒了一遍——结果发现广播这个词用在这儿本身就是个误会而那 5% 的来源比想象的有意思得多。如果你是做车载、做音频、做任何要对接经典蓝牙BR/EDR的嵌入式设备这个现象迟早会砸到你头上测试拿着扫描列表来问这个设备是不是有问题名字怎么没扫到是不是被你广播丢了带着这个问题我读了一轮 Zephyr 蓝牙协议栈v3.3.0subsys/bluetooth/host/classic/br.c的源码。结论比丢没丢有意思得多——BT 扫描里的名字走的是一条两级降级机制而这条机制的失败路径狠到很多人想象不到。一、先把 name 的完整判别树画清楚本文核心先说清一个概念经典蓝牙的发现流程是发现方主动发 Inquiry被发现方在 inquiry scan 信道上应答。应答可能带 EIRExtended Inquiry Result最多 240 字节扩展数据名字就藏在 EIR 里。一条扫描结果最终有没有名字取决于下面这棵判别树这棵树上有三个关键认知先立住后面逐个展开EIR 里带了名字 必然拿到。对支持 EIR 且带名字 TLV 的设备扫描结果只有扫到了和没扫到两种情况——没有扫到了但名字丢了这个中间态。EIR 没带名字 ≠ 最终名字为空。协议栈的补查是默认必走的一环不是可选项——绝大多数 EIR 没带名字的设备名字都能被补查救回来。最终空名字的唯一来源是补查失败。这才是那 5% 的真正出处。二、第一级EIR 应答直接带名字——这条路没有概率先看第一级。EIR 里为什么会有名字这涉及一个反直觉的事实Zephyr host 从头到尾只发过一次Write_Local_Name写入本地名字从来没有发过写 EIR的命令——EIR 里的名字是controller 自动代劳填进去的controller 把 local name 填进 EIR 的 0x09Complete Local NameTLV应答 Inquiry 时随包直接发出不需要发现方二次请求。所以对 EIR 带名字的设备发现方一次 Inquiry名字就在应答里完整到手。实测规律完全印证凡是 EIR 里带名字的设备每次扫描名字都完整没有丢失。扫到了但名字丢了这个猜想在这条路径上不成立。那 EIR 里没名字 TLV 的原因有哪几种设备压根没设置 local name——Write_Local_Name没写过controller 想代劳也没料controller 不代劳——规范要求填但各家 controller 实现有差异有的不往 EIR 里填名字老古董设备——只回普通 Inquiry Result无 EIR名字 TLV 自然无从谈起。注意这三种情况在发现方 host 眼里是同一件事收到的 EIR 数据里没有名字 TLV。host 用eir_has_name()br.c:303做判断——这个函数只做一件事在已收到的应答数据里找有没有 0x08/0x09 类型的 TLV它本身不发任何请求、查不到任何新东西。查到了就完事查不到交给下一级。三、第二级Remote Name Request 补查——默认必走的一环Inquiry Complete 之后host 对本轮所有结果做一次盘点check_request_name()br.c:346遍历每条结果凡是eir_has_name()返回没有的逐个发Remote Name RequestLMP 层的单挑请求单独去问对端你叫什么。流程串起来Inquiry Result with RSSI→ 登记结果槽位Extended Inquiry Result→ 保存 EIR可能含名字逐条回调bt_br_discovery_cb.recv()Inquiry Complete→check_request_name()盘点对无名字的逐个发 Remote Name Request名字拿到后以EIR_SHORT_NAMETLV 补进结果bt_hci_remote_name_request_complete()br.c:543全部补完timeout()回调上报最终列表这就是两级降级第一级EIR 应答时直接带名字第一级落空第二级 Remote Name Request 单独补查。正因为有这级补查EIR 没带名字的设备大多数名字都能到手——最终列表里的空名字实际是小概率事件。设计意图很清楚宁可逐个发请求也要尽量让列表里每一条都有名字——因为经典蓝牙是人选设备列表里没有名字的设备用户看不懂、不敢选、等于连不上。这和 BLE 完全是两个世界BLE 是程序按 MAC 地址选设备名字缺失不影响连接。这个对比值得单开一篇细说。到这里一切都很美好。但源码往下读几行就会撞到那个狠角色——5% 的真正来源。四、狠角色失败一次永久放弃本轮扫描就地终结看bt_hci_remote_name_request_complete()br.c:543的处理注意顺序priv-resolve_state RESOLVE_REMOTE_NAME_RESOLVED; // 先无条件标记已完成 if (evt-status) { goto check_names; // 失败不写名字直接跳走 } /* ……只有成功才把名字写进 result-eir */ check_names: if (check_request_name()) { return; // 只重发 state 仍为 PENDING 的设备 } atomic_clear_bit(bt_dev.flags, BT_DEV_INQUIRY); // 全部 RESOLVED → 结束本轮 listener-timeout(discovery_results, discovery_results_count);两个要命的细节第一失败即终态。resolve_state在检查evt-status之前就被置成了 RESOLVED。即不管这次 Remote Name Request 成没成功这条设备都被标记为处理完了——而check_request_name()只会对状态还是 PENDING 的设备发请求。失败一次 这条设备的名字被永久放弃本轮扫描里不会再有第二次机会。而 Remote Name Request 会偶发失败对端恰好不在 page scan 上、射频抖了、时序没对齐一次没应上就成了。这就是实测里那 5% 左右空 name 的机制性来源。每一次补查失败就落出一条空名字的记录且当轮无法挽回。第二扫描随之终结。当所有设备都进入 RESOLVED不管成败BT_DEV_INQUIRY标志被清除timeout()回调把最终结果上报——含着那条没名字的记录然后本轮 Inquiry 彻底结束。对着用户看现象就是列表里出现一条地址/信号都在、名字为空的设备然后扫描停止了。看起来特别像名字丢了、扫描也坏了协议栈却按部就班走完了流程只是那条失败记录被悄悄埋了。五、解法重扫一轮就这一招搞清机制解法反而不玄乎。某条设备没名字别修广播也别怀疑丢包重新发起一轮 discovery 就行。新一轮会重新 Inquiry、重新走一遍 Remote Name Request上次要是偶发失败这次大概率就补上了。反过来重扫一次能补上名字的是偶发重扫十次还是空的就是那台设备真的没设名字或不在 page scan 上。轮次时长给个参考Inquiry 时长按 HCI Inquiry 的时间片走单位是 1.28 秒bt_br_discovery_start()的param-length就是这个单位。单轮设 12 秒上下9~10 个时间片单位比较合适——真实设备一般在 5 秒内就能被扫到超过 20 秒新增发现明显变少再等下去收益有限。如果是产品里的持续扫描界面别停一次就完15 秒一轮循环重启顺带把上一轮空名字的设备再补查一次。想实锤这条链路开CONFIG_BT_DEBUG_LOG盯bt_hci_remote_name_request_complete收到的 status 码和check_request_name()的走向失败还是成功一目了然。如果你的产品是被发现方把Write_Local_Name的名字写对就够了。名字进 EIR 是 controller 代劳的这一处写对第一级就稳了根本走不到那个失败即放弃的岔路口。六、小结回看开头的判别树name 的三种命运现在都清楚了EIR 带名字→ 必然完整到手100% 稳定谈不上丢EIR 没带→ 默认补查救回绝大多数仍有名字补查失败→ 空 name实测约 5%当轮永久放弃重扫一轮是唯一补救。顺带留个引子文中反复提到经典蓝牙的广播和 BLE 的广播根本不是一回事。一边是你喊我应答一边是我主动喊你听一边名字由 controller 代劳进 EIR一边要应用自己决定放 ad 还是 sd。这两套机制的完整对比下一篇展开敬请期待。你在扫描列表里见过空名字的设备吗最后查明原因了吗评论区聊聊。觉得有用点个在看让更多踩这个坑的兄弟看到。系列衔接本系列下一篇《经典蓝牙 Inquiry 与 BLE 广播机制对比基于 Zephyr 源码》讲清两套发现机制的设计哲学差异。嵌入式 蓝牙 经典蓝牙 Zephyr 源码分析
一句话先答不是名字丢了——名字的获取有一条两级降级机制兜底最终的空名字是小概率的漏网之鱼实测 5% 左右而漏网的根源是补查失败一次就永久放弃。做蓝牙的兄弟大概都见过这个场景手机开蓝牙一扫列表里大部分设备都有名字——小米电视、JBL Flip 6、XXX耳机可总有那么一两条地址、信号强度都在名字那栏空着。我们项目里就是这么撞上的实测某个海思平台扫描结果里 name 为空的比例稳定在5% 左右。就是这个不起眼的 5%逼着我们把经典蓝牙的发现机制从头扒了一遍——结果发现广播这个词用在这儿本身就是个误会而那 5% 的来源比想象的有意思得多。如果你是做车载、做音频、做任何要对接经典蓝牙BR/EDR的嵌入式设备这个现象迟早会砸到你头上测试拿着扫描列表来问这个设备是不是有问题名字怎么没扫到是不是被你广播丢了带着这个问题我读了一轮 Zephyr 蓝牙协议栈v3.3.0subsys/bluetooth/host/classic/br.c的源码。结论比丢没丢有意思得多——BT 扫描里的名字走的是一条两级降级机制而这条机制的失败路径狠到很多人想象不到。一、先把 name 的完整判别树画清楚本文核心先说清一个概念经典蓝牙的发现流程是发现方主动发 Inquiry被发现方在 inquiry scan 信道上应答。应答可能带 EIRExtended Inquiry Result最多 240 字节扩展数据名字就藏在 EIR 里。一条扫描结果最终有没有名字取决于下面这棵判别树这棵树上有三个关键认知先立住后面逐个展开EIR 里带了名字 必然拿到。对支持 EIR 且带名字 TLV 的设备扫描结果只有扫到了和没扫到两种情况——没有扫到了但名字丢了这个中间态。EIR 没带名字 ≠ 最终名字为空。协议栈的补查是默认必走的一环不是可选项——绝大多数 EIR 没带名字的设备名字都能被补查救回来。最终空名字的唯一来源是补查失败。这才是那 5% 的真正出处。二、第一级EIR 应答直接带名字——这条路没有概率先看第一级。EIR 里为什么会有名字这涉及一个反直觉的事实Zephyr host 从头到尾只发过一次Write_Local_Name写入本地名字从来没有发过写 EIR的命令——EIR 里的名字是controller 自动代劳填进去的controller 把 local name 填进 EIR 的 0x09Complete Local NameTLV应答 Inquiry 时随包直接发出不需要发现方二次请求。所以对 EIR 带名字的设备发现方一次 Inquiry名字就在应答里完整到手。实测规律完全印证凡是 EIR 里带名字的设备每次扫描名字都完整没有丢失。扫到了但名字丢了这个猜想在这条路径上不成立。那 EIR 里没名字 TLV 的原因有哪几种设备压根没设置 local name——Write_Local_Name没写过controller 想代劳也没料controller 不代劳——规范要求填但各家 controller 实现有差异有的不往 EIR 里填名字老古董设备——只回普通 Inquiry Result无 EIR名字 TLV 自然无从谈起。注意这三种情况在发现方 host 眼里是同一件事收到的 EIR 数据里没有名字 TLV。host 用eir_has_name()br.c:303做判断——这个函数只做一件事在已收到的应答数据里找有没有 0x08/0x09 类型的 TLV它本身不发任何请求、查不到任何新东西。查到了就完事查不到交给下一级。三、第二级Remote Name Request 补查——默认必走的一环Inquiry Complete 之后host 对本轮所有结果做一次盘点check_request_name()br.c:346遍历每条结果凡是eir_has_name()返回没有的逐个发Remote Name RequestLMP 层的单挑请求单独去问对端你叫什么。流程串起来Inquiry Result with RSSI→ 登记结果槽位Extended Inquiry Result→ 保存 EIR可能含名字逐条回调bt_br_discovery_cb.recv()Inquiry Complete→check_request_name()盘点对无名字的逐个发 Remote Name Request名字拿到后以EIR_SHORT_NAMETLV 补进结果bt_hci_remote_name_request_complete()br.c:543全部补完timeout()回调上报最终列表这就是两级降级第一级EIR 应答时直接带名字第一级落空第二级 Remote Name Request 单独补查。正因为有这级补查EIR 没带名字的设备大多数名字都能到手——最终列表里的空名字实际是小概率事件。设计意图很清楚宁可逐个发请求也要尽量让列表里每一条都有名字——因为经典蓝牙是人选设备列表里没有名字的设备用户看不懂、不敢选、等于连不上。这和 BLE 完全是两个世界BLE 是程序按 MAC 地址选设备名字缺失不影响连接。这个对比值得单开一篇细说。到这里一切都很美好。但源码往下读几行就会撞到那个狠角色——5% 的真正来源。四、狠角色失败一次永久放弃本轮扫描就地终结看bt_hci_remote_name_request_complete()br.c:543的处理注意顺序priv-resolve_state RESOLVE_REMOTE_NAME_RESOLVED; // 先无条件标记已完成 if (evt-status) { goto check_names; // 失败不写名字直接跳走 } /* ……只有成功才把名字写进 result-eir */ check_names: if (check_request_name()) { return; // 只重发 state 仍为 PENDING 的设备 } atomic_clear_bit(bt_dev.flags, BT_DEV_INQUIRY); // 全部 RESOLVED → 结束本轮 listener-timeout(discovery_results, discovery_results_count);两个要命的细节第一失败即终态。resolve_state在检查evt-status之前就被置成了 RESOLVED。即不管这次 Remote Name Request 成没成功这条设备都被标记为处理完了——而check_request_name()只会对状态还是 PENDING 的设备发请求。失败一次 这条设备的名字被永久放弃本轮扫描里不会再有第二次机会。而 Remote Name Request 会偶发失败对端恰好不在 page scan 上、射频抖了、时序没对齐一次没应上就成了。这就是实测里那 5% 左右空 name 的机制性来源。每一次补查失败就落出一条空名字的记录且当轮无法挽回。第二扫描随之终结。当所有设备都进入 RESOLVED不管成败BT_DEV_INQUIRY标志被清除timeout()回调把最终结果上报——含着那条没名字的记录然后本轮 Inquiry 彻底结束。对着用户看现象就是列表里出现一条地址/信号都在、名字为空的设备然后扫描停止了。看起来特别像名字丢了、扫描也坏了协议栈却按部就班走完了流程只是那条失败记录被悄悄埋了。五、解法重扫一轮就这一招搞清机制解法反而不玄乎。某条设备没名字别修广播也别怀疑丢包重新发起一轮 discovery 就行。新一轮会重新 Inquiry、重新走一遍 Remote Name Request上次要是偶发失败这次大概率就补上了。反过来重扫一次能补上名字的是偶发重扫十次还是空的就是那台设备真的没设名字或不在 page scan 上。轮次时长给个参考Inquiry 时长按 HCI Inquiry 的时间片走单位是 1.28 秒bt_br_discovery_start()的param-length就是这个单位。单轮设 12 秒上下9~10 个时间片单位比较合适——真实设备一般在 5 秒内就能被扫到超过 20 秒新增发现明显变少再等下去收益有限。如果是产品里的持续扫描界面别停一次就完15 秒一轮循环重启顺带把上一轮空名字的设备再补查一次。想实锤这条链路开CONFIG_BT_DEBUG_LOG盯bt_hci_remote_name_request_complete收到的 status 码和check_request_name()的走向失败还是成功一目了然。如果你的产品是被发现方把Write_Local_Name的名字写对就够了。名字进 EIR 是 controller 代劳的这一处写对第一级就稳了根本走不到那个失败即放弃的岔路口。六、小结回看开头的判别树name 的三种命运现在都清楚了EIR 带名字→ 必然完整到手100% 稳定谈不上丢EIR 没带→ 默认补查救回绝大多数仍有名字补查失败→ 空 name实测约 5%当轮永久放弃重扫一轮是唯一补救。顺带留个引子文中反复提到经典蓝牙的广播和 BLE 的广播根本不是一回事。一边是你喊我应答一边是我主动喊你听一边名字由 controller 代劳进 EIR一边要应用自己决定放 ad 还是 sd。这两套机制的完整对比下一篇展开敬请期待。你在扫描列表里见过空名字的设备吗最后查明原因了吗评论区聊聊。觉得有用点个在看让更多踩这个坑的兄弟看到。系列衔接本系列下一篇《经典蓝牙 Inquiry 与 BLE 广播机制对比基于 Zephyr 源码》讲清两套发现机制的设计哲学差异。嵌入式 蓝牙 经典蓝牙 Zephyr 源码分析
