这个是对端Nuki Fob client 发给 S3 server 的数据，我们也不理对端行为和那些数据代表啥，需要你去研究下
那个断开是 0x08 超时断开，你抓下包看看是不是有一端在监督超时时间内没有回复包，抓包文件也可以发下

可以在 ESP_GATTS_CONNECT_EVT 中获取到手机 mac 地址，不能获取到手机设备名称

ESP32C3 不支持经典蓝牙，那些选项是经典蓝牙的配置选项 ESP32 支持经典蓝牙，可参考运行以下目录中的示例： https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/bluedroid/classic_bt ESP32C3 有使用 ble 模拟 SPP profile 的示例 ble_spp_server 和 ble_spp_client，也可以进行参考下： https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/bluedro...

如果你要使用 slave 进行发 exchange MTU request 的包，可以参考下附件中这个示例 使用方法是手机 APP 如BLE 调试助手搜索到 “ESP_GATTS_DEMO”广播进行连接，并进行抓包，从抓包中可以看到是由 slave 发出的 exchange MTU request 的包 你实际应用中可以参考这个进行更改，

可以先跑跑这个目录下的示例: https://github.com/espressif/esp-idf/tr ... edroid/ble
最基础的示例是 gatt_client 和 gatt_server_service_table(或者 gatt_server)

获取 RSSI 值可以使用 esp_ble_gap_read_rssi 函数，在 ESP_GAP_BLE_READ_RSSI_COMPLETE_EVT 事件获取到结果
如果 C3 进行扫描， 可以在扫描结果事件中 获取到 广播者的 RSSI 值

接上文， tu4 你目前需求是使用 S3 连接 Nuki 蓝牙设备， 连接是能正常连接的， 场景1 也是正常连接，但是 Nuki 蓝牙设备作为 client 有一定的应用层逻辑，每 5s 进行应用层主动断开一次，需要搞清楚为什么主动断开？

其实这个和 交换 MTU 的操作没有关系，不交换 MTU 大家都使用 默认 23 也可以进行通信

1、第一种场景—— ESP32S3(Gatt Server) 和 Nuki Fob(Client) 连接(Pairing) 从 ESP32S3 Gatt Server - Nuki Fob 日志中可以看到有 8次 0x13 断连(原因： 对端主动断开), 和一次 0x08 的断连(原因： 超时断开) 从 ESP32S3-Nuki Fob.pcapng 中可以看到连接是正常的，但是 master 每 5 秒会主动断开一次， 如tu1 tu1.png 最后一次是超时断开， master 超过 3s(连接请求中的 timeout ) 没有回包， 连接断开，如tu2 tu2.png 2、第二种场景——...

你好，
麻烦你提供下以下文件：
1. ESP32S3和Nuki Fob 连接的一个完整日志 和相对应的抓包文件
2. 两个 Nuki Fob 连接 连接的抓包文件

单从提供的截图信息不太好分析出原因，server slave 在协议中是不能发送 MTU request 的，所以我们也很奇怪这个抓包，麻烦你发下完整的 wireshark 抓包文件，我们会尽快分析和给出结论 上图是我的抓包显示，我所指的 connct event counter 是如上“Event counter” 数值

第一个图是可以查看 exchange MTU 包的 count event counter ，这个可以看出包的前后顺序

第二个图原因应该不在 exchange MTU， 看后面的连接参数被拒绝，应该是这个导致的， exchange MTU 的包可能没被抓到，或者在后面
不太清楚 master 需求怎样的连接参数，一般是调大些连接间隔

server 不能发送 mtu exchange request , 只是对 client 发出的 request 作出应答