基于Gatt Server ESP32S3 和 Nuki Fob 连接 出现 ESP_BT_STATUS_PARAM_OUT_OF_RANGE 问题

[workhard10]

我在做一个项目， 目的是让 ESP32-S3-DevkitC-1开发板 和 Nuki Fob 通过 Pairing 连接。 我使用 Gatt Server例程 作为开发主体/基准的。

在Pairing 连接过程中发生了如下的报错: 请看 FOB.JPG

Status = 15 表示 ESP_BT_STATUS_PARAM_OUT_OF_RANGE 错误。

我尝试更改过

Code: [Select all] [Expand/Collapse]

1.         conn_params.latency = 0;
2.         conn_params.max_int = 0x20;    // max_int = 0x20*1.25ms = 40ms
3.         conn_params.min_int = 0x10;    // min_int = 0x10*1.25ms = 20ms
4.         conn_params.timeout = 200;

GeSHi © Codebox Plus Extension

但是好像 数据不够长似的， latency, max_int, min_int, 都能更改，timeout怎么改，程序运行后观察Terminal，timeout的数值始终不变化。

作为类比，我尝试过Nuki API 上的一个Pairing例子，让ESP32S3 和NUKI APP连接， 我观察了Terminal， 一切正常，能得到期望的结果，请参看APP.JPG.

两者运行的区别在于 ESP32S3 与 FOB 连接时，没有放生 ESP_GATTS_MTU_EVT, MTU 500, 看样子没有设置MTU的数值，谁知道这是为什么呢?按道理来说FOB 与 APP 分别与 ESP32S3 连接的细节过程应该是一样的， 谁能给解释一下，谢谢了！！！

[ESP_XuLZ]

gatt_server 示例是不可以配对的，如果需要进行配对，可以使用 gatt_security_server 示例
看日志应该是更新连接参数引起的 client 主动断连， 你将更新的连接参数值 连接间隔、超时时间都适当调大试试
或者将 S3 上更新连接参数的 esp_ble_gap_update_conn_params 先注释掉

如果需要配对，使用 gatt_security_server ，提供下完整的日志

[workhard10]

谢谢你的答复， 我最近又尝试了一下，发现问题出在 ESP32S3 与 NUKI Fob 没有发生 MTU exchang, 从而导致后面数据上传发生错误。

我的问题是，如何让GATT Server 发送 "MTU exchang request"?

我看见有

Code: [Select all] [Expand/Collapse]

1. esp_err_t esp_ble_gattc_send_mtu_req(esp_gatt_if_t gattc_if, uint16_t conn_id)

GeSHi © Codebox Plus Extension

这个API函数，但是它是供 Gatt Client 使用的。有没有办法让 GATT Server 发送 "MTU exchang request"?

似乎不太可思议，我也觉得很奇特，用 GATT Server 发送 "MTU exchang request"， 但是在蓝牙5 规范中 "BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part G: 4.3 SERVER CONFIGURATION, 确实有关于用GATTServer 发送 "MTU exchang request" 的描述，在ESP32 中我如何实现呢?

[ESP_XuLZ]

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

企业微信截图_20221128094052.png (18.66 KiB) Viewed 8812 times

[workhard10]

谢谢，这个插图我也有看过，Client 发送 MTU Exchange request 确实如此！

我这里有有个截图，我用 nrf52840 dongle 和wireshark 观察了 NUKI Lock 和 NUKI Fob 的连接， 请参见 "NukiLock-Fob.JPG",

NukiLock-Fob.JPG (181.69 KiB) Viewed 8796 times

图中，在LL_SLAVE_FEATURE_REQ 发生之后， Nr.1 和 Nr.2 所标注的是 MTU Exchange 过程，我检查过了，NukiLock 在 这里是 Server(Slave)， 似乎还真是Server先发送了Rcvd Exchange MTU Request 给 Fob(Client, Master). 真是奇了怪了。

当ESP32S3与Nuki Fob 发生连接时，请参看 "ESP32-Fob.JPG",

ESP32-Fob.JPG (196.38 KiB) Viewed 8796 times

图中， 在LL_SLAVE_FEATURE_REQ 发生之后，则没有出现 MTU Exchange 过程。

我真的非常困惑，查阅了很多东西，都不知道为什么，为什么我的ESP32-S3_DevKitC-1 无法与Nuki Fobi发生连接。。。就是这个MTU Exchange 过程他怎么就不发生呢。。。到底缺失了什么东西在 ESP32S3和Nuki Fob之间。这里我的ESP32S3 是使用官方Gatt Server 例程为基础的。

期待大神的回答！

[ESP_XuLZ]

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

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

[workhard10]

NukiLock-Fob new.JPG (180.92 KiB) Viewed 8762 times

请看图一 NukiLock-Fob new.JPG，我是用Nuki Lock 和 Nuki Fob 进行成功Pairing的，Pairing完成后， Nuki Fob 也确实可以成功控制 Nuki Lock的。所以可以说，图一是一个正确的参照图. 其中红色Nr.3 也发生了 Connection Parameter Update Reponse(Rejected), 我问过 Nuki 的工作人员，他们确认这是正确现象。
红色标注的Nr.1 和 Nr.2 分别对应了 count event counter 0 和 1。 即: Nuki Lock(Server/Slave) 先发送了"MTU Exchange Request" 给 Nuki Fob(Client/Master) ， 随后 Nuki Fob(Client/Master) 又 回发了"MTU Exchange Response"给 Nuki Lock(Server/Slave)。

ESP32-Fob new.JPG (192.98 KiB) Viewed 8762 times

请看图二 ESP32-Fob new.JPG， 其中红色Nr.3 也发生了 Connection Parameter Update Reponse(Rejected), 唯一缺失是 LL_SLAVE_FEATURE_REQ 后面发生的 "MTU Exchange"过程。 而且需要的是 Gatt Server 先发送 "MTU Exchange Request" 给Gatt Client的过程。

这里是ESP32论坛,希望有你们专业的人员能指点我， 能否实现， 怎样实现， Gatt Server 先发送 "MTU Exchange Request" 给Gatt Client.

此外，能否解释一下，为什么会有 发生 Gatt Server 先发送 "MTU Exchange Request" 给Gatt Client的过程，因为一般来说都是 Gatt Client 先发送 "MTU Exchange Request" 给Gatt Server

期待你们快速的回复！

[ESP_XuLZ]

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

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

企业微信截图_20221130105859.png (90.99 KiB) Viewed 8712 times

上图是我的抓包显示，我所指的 connct event counter 是如上“Event counter” 数值

[workhard10]

你好，非常感谢你们的关注。我做了一下整理。一共有如下情况的连接:

1. ESP32S3(Gatt Server) 和 Nuki Fob(Client) 连接(Pairing), 有 Espressif-IDE 的日志，和相应的抓包
请参见文件:
ESP32S3 Gatt Server - Nuki Fob 日志.txt (也可以从文章最后提到的Cloud下载)

ESP32S3 Gatt Server - Nuki Fob 日志.txt

(9.51 KiB) Downloaded 361 times

ESP32S3-Nuki Fob.pcapng (请从文章最后提到的Cloud下载)

2. ESP32S3(Gatt Server) 和 Nuki APP(Client) 连接(Pairing), 有 Espressif-IDE 的日志，和相应的抓包
请参见文件:
ESP32S3 Gatt Server - Nuki APP 日志.txt (也可以从文章最后提到的Cloud下载)

ESP32S3 Gatt Server - Nuki APP 日志.txt

(5.39 KiB) Downloaded 357 times

ESP32S3-Nuki APP.pcapng (请从文章最后提到的Cloud下载)
20200316NukiSmartLockAPI2_1.pdf (也可以从文章最后提到的Cloud下载)

20200316NukiSmartLockAPI2_1.pdf

(366.9 KiB) Downloaded 479 times

这里只是说明，当ESP32S3(Gatt Server) 与 Nuki APP(Client) 发生 连接(Pairing)的时候，情况还是符合逻辑的，在 "20200316NukiSmartLockAPI2_1.pdf" NUKI Lock API 官方文件的 74 页，第一个例子"Authorize APP", ESP32S3 (作为 SL)确实得到了从NUKI APP(作为CL) 发出的Request "0100 0300 27A7", 在 "ESP32S3 Gatt Server - Nuki APP 日志.txt" 日志最后一行，确实也是 "01 00 03 00 27 a7".
在"ESP32S3-Nuki APP.pcapng" 中关于 "MTU Exchange" 的交换也合情合理，即 Nuki Lock(Client/Master) 先发送 "MTU Exchange Request" 给ESP32S3(Server/Slave)的。时态的发展全部合情合理。提供给你们，或许你们也需要这种情况做参考。以便达到我的最终目的，实现ESP32S3与Nuki Fob的成功连接(Pairing)。

3. Nuki Lock(Gatt Server) 和 Nuki Fob(Client) 连接(Pairing), 我身边有两个 Nuki
Fob, 所以我做了两次和 Nuki Lock 的 连接(Pairing)尝试，都成功了， 两个 Nuki Fob 都可以Nuki Lock 正常工作。相应的抓包文件如下:
Nuki Lock- Nuki Fob_1.pcapng (请从文章最后提到的Cloud下载)
Nuki Lock- Nuki Fob_2.pcapng (请从文章最后提到的Cloud下载)
nuki-fob-2nd-generation-manual.pdf (请从文章最后提到的Cloud下载)
Nuki Lock(Gatt Server) 和 Nuki Fob(Client) 连接(Pairing) 过程请参见说明书"nuki-fob-2nd-generation-manual.pdf"中的 "A) Pairing directly via Bluetooth (Nuki Fob 2nd generation)"章节。
两次的抓包文件中分别包含了 连接(Pairing) 过程 成功后，我按 Nuki Fob 上的按钮两次(一下"开"，一下"关")，以确认Nuki Fob是否真的连接(Pairing)成功 可以操作Nuki Lock了。事实证明确实接(Pairing)成功，Nuki Fob 可以操作Nuki Lock "开" 和 "关" 了。

剩下的问题，就是之前我们讨论那么久的关于 "MTU Exchange Request" 的发送问题了，似乎在 Nuki Lock(Gatt Server) 和 Nuki Fob(Client) 连接(Pairing) 连接的情况下，是 Nuki Lock(Gatt Server/Slave) 先向 Nuki Fob(Client/Master) 发送了"MTU Exchange Request"，这个操作真是让我抓狂，我也各种问过Nuki公司关于这个抓包现象，但是目前为止还没回应。

因为我是想用ESP32S3来仿真Nuki Lock，从而实现我的最终目的:ESP32S3和Nuki Fob的连接(Pairing)成功但是现在的情况让我很难进行下去。。。正如所说的，ESP32S3(Gatt Server) 无法向 Nuki Fob(Client) 发送"MTU Exchange Request"

所以希望你们能帮助看一下，给一些启示。非常感谢！！

此外我发现我的文件可能太多，你们的论坛附件似乎装不下，而且也不支持抓包文件 *.pcapng 附件，所以我提供了一个我Cloud链接，里面有上文中提到的所有相关文件下载。期待你们的回复!
Cloud链接: https://cloud.siegenia.com/s/kxEztjCdctAj8my

[ESP_XuLZ]

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 (169.38 KiB) Viewed 8636 times

最后一次是超时断开， master 超过 3s(连接请求中的 timeout ) 没有回包， 连接断开，如tu2

tu2.png (147.77 KiB) Viewed 8636 times

2、第二种场景—— ESP32S3(Gatt Server) 和 Nuki APP(Client) 连接(Pairing)
从 ESP32S3 Gatt Server - Nuki APP 日志中看到连接正常，有 MTU 交换的操作， 从抓包中看也是正常的 client 发起的连接请求， 如 tu3

tu3.png (155.09 KiB) Viewed 8636 times

3、第三种场景—— Nuki Lock(Gatt Server) 和 Nuki Fob(Client) 连接(Pairing),
从抓包 Nuki Lock- Nuki Fob_1.pcapng 上看确实有 slave 发给 master exchange MTU 的请求，如 tu4, 一种可能性是 client 的底层对应 slave role, server 的底层对应 master role , 但这种操作不太符合常理，你可以去 Nuki 厂商确认这个事情