May 17, 2026 3:30 AM - I had successfully testing the CPP classes on the 2 Rapsberry Pi Zero 2Ws using the Constitution. I then queried Codex and ask: how could I be certain I was ussing the compiled CPP library and not the older Python code. It made changes which I did not examine which would regurgitate what it was using. I pushed to Forgejo and then pulled to Zeros. That's when things went south. Suddenly the Constitution was not being cross transmitted in 36 seconds and the 60 seconds timeout trigger resulting in an incomplete transfer on both side. Then, I think, more modifications were made and deployed and then the BLE could not even advertise and/or register. Codex suggestion was to reboot the Pis. This is where I disagreed. Here is an opportunit to take a rock-solid hardware state and learn why it was disturbed, if it was disturbed. This occured about 6 hours ago on Saturday evening, May 15th. I've awakened and mulled this over and realized this may be an opportunity to identify a more low level bug. The latest runs were tmp/run13 where a connection could not even be established.
So, I'll do run14 using the exact same command clumps to see if the condition remains, or if the passage of time has changed something. Hopefully, run14 will have the same errors.
I'll also source control my Pi command clumps.
May 17, 2026 3:39 AM Using existing ssh shells, I reran the test and duplicated the error condition. Saved in run14. zerodev1 has announcements and no indication of error. zerodev2 has errors:
```bash
[03:39:27.352] Requesting path to <926e6d3b35b7d5940be7edeb47c41b78>
[2026-05-17 03:39:28] [Critical] BLEInterface[BLE Interface] driver critical: Scanner callback failure detected (0 callbacks for 19 consecutive scans). Bluetooth stack requires reboot. - Exception: BleakScanner callbacks not invoked
```
Codex advises:
```
Run14 supports “low-level BLE/scanner path,” not C++ fragmentation:
zerodev2 is forced Python.
It advertises successfully.
It never establishes a path/link.
It repeatedly reports BleakScanner callbacks not invoked.
zerodev1 shows no scanner callback errors in the shown log.
So the immediate code point to instrument is LinuxBluetoothDriver._perform_scan(), around BleakScanner(... detection_callback=...), scanner.start(), scanner.stop(), and callback_count[0] == 0.
So I'll try a run with no change on zerodev1, but force "cpp" for zerdev2, I'll keep the logs in run14.
May 17, 2026 4:45 AM Did a lot of forensics for run 14, finally concluded a reboot of both was last resort. Also, created symlinks under ~/.reticulum/interfaces to this project's files. Previous runs may not have been using the "shim" given static file under ~/.reticulum/interfaces. For example:
```bash
So this discrepancy may invalidate all prior testing? Should I try using soft links under ~/.reticulum/interfaces pointing to the git controlled project files?
jlpoole@zerodev1:/usr/local/src/ble-reticulum $ ls src/ble_reticulum/ -la
total 312
drwxrwxr-x 3 jlpoole jlpoole 4096 May 16 20:28 .
drwxrwxr-x 3 jlpoole jlpoole 4096 May 15 11:25 ..
-rw-rw-r-- 1 jlpoole jlpoole 9891 May 16 08:11 BLEAgent.py
-rw-rw-r-- 1 jlpoole jlpoole 20471 May 15 11:25 BLEFragmentation.py
-rw-rw-r-- 1 jlpoole jlpoole 2433 May 16 19:36 BLEFragmentationBackend.py
-rw-rw-r-- 1 jlpoole jlpoole 27232 May 16 08:11 BLEGATTServer.py
-rw-rw-r-- 1 jlpoole jlpoole 120620 May 16 20:28 BLEInterface.py
-rw-rw-r-- 1 jlpoole jlpoole 0 May 15 11:25 __init__.py
drwxrwxr-x 2 jlpoole jlpoole 4096 May 16 19:37 __pycache__
-rw-rw-r-- 1 jlpoole jlpoole 7340 May 15 11:25 bluetooth_driver.py
-rw-rw-r-- 1 jlpoole jlpoole 107923 May 16 08:11 linux_bluetooth_driver.py
jlpoole@zerodev1:/usr/local/src/ble-reticulum $ ls ~/.reticulum/interfaces/ -la
total 308
drwxrwxr-x 3 jlpoole jlpoole 4096 May 15 16:35 .
drwxrwxr-x 4 jlpoole jlpoole 4096 May 16 07:43 ..
-rw-rw-r-- 1 jlpoole jlpoole 9751 May 15 12:19 BLEAgent.py
-rw-rw-r-- 1 jlpoole jlpoole 20471 May 15 12:19 BLEFragmentation.py
-rw-rw-r-- 1 jlpoole jlpoole 27092 May 15 12:19 BLEGATTServer.py
-rw-rw-r-- 1 jlpoole jlpoole 119128 May 15 12:19 BLEInterface.py
-rw-rw-r-- 1 jlpoole jlpoole 0 May 15 12:19 __init__.py
drwxrwxr-x 2 jlpoole jlpoole 4096 May 15 16:35 __pycache__
-rw-rw-r-- 1 jlpoole jlpoole 7340 May 15 12:19 bluetooth_driver.py
-rw-rw-r-- 1 jlpoole jlpoole 107783 May 15 12:19 linux_bluetooth_driver.py
jlpoole@zerodev1:/usr/local/src/ble-reticulum
```
I tried CPP versions and I extended the timeout from 60 seconds to 90, the previous 60 was cutting it too close, though at the very early tests, the Constitution could be transferred in 36 seconds, so note should be made that something was introduced that slowed the transfer down.
May 17, 2026 1:21 PM Identities CPP works and tested in field with bilateral Constitution test. Report: migration/reports/identities_20260517_report.md
So `zerodev1` scanner callbacks are not fundamentally broken. They work when there is a known advertiser.
The confusing part is on `zerodev2`: while advertising successfully, its own scanner loop reports:
```text
Scanner callback failure detected (0 callbacks for 3...13 consecutive scans)
```
That may be a false-positive in quiet RF conditions or while the other Pi is not advertising. The current detector treats “zero callbacks” as a Bluetooth stack failure, but your evidence now shows zero callbacks can happen even while the node is otherwise healthy enough to register advertisements, and `btmgmt find` is not reliable on this platform.
My updated interpretation:
-`btmgmt find` should be removed from the health criteria for these Pis.
- “0 Bleak callbacks” should not automatically mean “Bluetooth stack requires reboot” unless there is a known advertiser expected during that scan window.
- The scanner callback critical log in `linux_bluetooth_driver.py` is likely too aggressive for this environment.
- The C++ backend is confirmed active in this run and is not implicated by these scanner warnings.
For the next code improvement, I would change the scanner diagnostic severity/message. Something like: after repeated zero-callback scans, log a warning that no BLE advertisements were observed, but do not call it “requires reboot” unless there is additional evidence such as scanner start failure, adapter not powered, HCI timeout, or known peer advertisement missed repeatedly.
That is separate from the protocol-core migration and should probably be handled as a BLE platform robustness fix.
Codex's carry-over summary for a new chat, Phase 2:
Yes, start a new chat for Phase 2. This one has a lot of forensic context mixed with migration work. Seed the new chat with this:
```text
Project: ble-reticulum migration to C++, Phase 2
Repo: /usr/local/src/ble-reticulum
Branch: c++migration
Current date context: May 17, 2026
Reticulum env on workstation: /home/jlpoole/rnsenv/bin/activate
On Pi Zero 2Ws I use system python3, not a venv.
Important current state:
- C++ protocol-core module exists under migration/protocol_core:
Also mention what you want Phase 2 to mean. Good candidates are:
```text
For Phase 2, I want to extract the next small protocol-only unit, with tests first, and avoid BLEInterface behavioral changes.
```
or:
```text
For Phase 2, I want to address the scanner false-positive diagnostic separately as a platform robustness fix.
```
May 18, 2026 2:36 PM - saved a copy of the SQLite database under sql/archive. Memorialized prompt for Phase 2A from ChatGPT in Codex_prompt_State2A_20250518_1433.md.
