Implements comprehensive BlueZ device state cleanup after connection failures
to prevent persistent "Operation already in progress" errors. This addresses
the issue where BlueZ maintains stale connection state after timeouts or
failures, preventing successful reconnection even after blacklist periods expire.
BlueZ State Cleanup Implementation:
- **Explicit client disconnect**: Call client.disconnect() in timeout and failure
exception handlers to release BlueZ resources
- **D-Bus device removal**: New _remove_bluez_device() method removes stale device
objects via BlueZ RemoveDevice() API
- **Post-blacklist cleanup**: Trigger BlueZ cleanup when peer is blacklisted after
reaching max_connection_failures (7 failures)
Impact:
- Enables successful reconnection after temporary connection failures
- Fixes persistent errors across blacklist periods
- Prevents BlueZ from maintaining corrupted connection state
- Particularly important for Android devices with MAC address rotation
Implementation Details:
- linux_bluetooth_driver.py:786-830: New _remove_bluez_device() method
- linux_bluetooth_driver.py:1029-1044: Timeout cleanup (disconnect + removal)
- linux_bluetooth_driver.py:1051-1066: Failure cleanup (disconnect + removal)
- BLEInterface.py:1270-1285: Post-blacklist cleanup hook
- tests/test_bluez_state_cleanup.py: 10 new tests (all passing)
Documentation Updates:
- BLE_PROTOCOL_v2.2.md: New troubleshooting section for persistent InProgress errors
- CLAUDE.md: Added to recent fixes list
- CHANGELOG.md: Comprehensive fix description
Related Issues:
- Addresses "Operation already in progress" errors persisting after connection timeouts
- Fixes reconnection failures after peer blacklisting
- Prevents BlueZ state machine corruption from abandoned BleakClient instances
Testing:
- All 10 new unit tests pass
- Cleanup methods properly handle missing devices and D-Bus unavailability
- Integration testing on Raspberry Pi pending
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The validation script checks ~/.reticulum/logfile for BLE interface
status, but this file is only created when rnsd is started with the
-s (service/syslog) flag.
Without -s flag:
- rnsd runs but doesn't write to ~/.reticulum/logfile
- Validation script fails: "Log file not found"
- Deployment appears successful but validation always fails
With -s flag:
- rnsd writes logs to ~/.reticulum/logfile
- Validation can check for "interface online" message
- Full deployment + validation cycle works
Note: Only affects manual rnsd startup (non-systemd path). Systemd
installations should have -s configured in the service file.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Enable subclassing BLEInterface with custom platform-specific drivers by
introducing a class-level driver_class attribute that can be overridden.
Changes:
- Import LinuxBluetoothDriver optionally with HAS_LINUX_DRIVER flag
- Add driver_class class attribute (defaults to LinuxBluetoothDriver)
- Check driver_class is not None before instantiation
- Use self.driver_class() instead of hardcoded LinuxBluetoothDriver()
- Log which driver is being used at initialization
This pattern enables platform-specific implementations like:
class AndroidBLEInterface(BLEInterface):
driver_class = AndroidBLEDriver
Without this pattern, subclasses would need to override __init__ entirely
to use a different driver, duplicating all initialization logic.
Implementation details:
- LinuxBluetoothDriver import wrapped in try/except with fallback to None
- Raises ImportError if driver_class is None and no override provided
- Maintains backward compatibility (LinuxBluetoothDriver used by default)
- All production features preserved (logging redirect, blacklist, rate
limiting, service UUID filtering, connection management)
Use case:
This pattern is used by the Columba Android app to integrate the Android
BLE stack via Chaquopy, overriding driver_class with AndroidBLEDriver
that bridges to Kotlin BLE APIs.
Testing:
- Default behavior unchanged (uses LinuxBluetoothDriver)
- Subclass override tested in columba/python/android_ble_interface.py
- No functional changes to existing BLE interface behavior
Completely refactored the deployment workflow to create separate
GitHub Actions nodes for each Pi, with independent deploy and
validation steps. This provides much better visibility and control.
New Architecture:
1. **setup** job: Parses PI_HOSTS into JSON matrix
2. **deploy** job: Matrix execution (one instance per Pi)
3. **validate** job: Matrix execution (one instance per Pi)
4. **summary** job: Aggregate results
GitHub Actions Graph View (2 Pis):
```
setup ━┳━> deploy-pi-0 ━> validate-pi-0
┗━> deploy-pi-1 ━> validate-pi-1
```
Features:
- **Parallel execution**: All Pis deploy simultaneously
- **Independent nodes**: Each Pi has its own deploy + validate node
- **fail-fast: false**: One Pi failure doesn't block others
- **Per-Pi logs**: Clean, isolated logs for each device
- **Comprehensive validation**:
* Wait 5s for startup
* Check rnsd process
* Verify BLE interface online (retry 3x with 3s delay)
* Check Bluetooth adapter powered
* Display adapter MAC address
- **Better error reporting**: Shows which specific Pi failed
- **Granular status**: See each Pi's status independently
Validation Checks:
✓ rnsd process running
✓ Log file exists
✓ No critical errors in logs
✓ "interface online" message found
✓ Bluetooth adapter powered
✓ Retry logic for startup delays
Benefits:
- Easier to identify which Pi has issues
- Can re-run individual Pi jobs
- Faster deployment (parallel vs sequential)
- Clearer progression in GitHub UI
- Each Pi's logs are isolated and clean
Example UI with failure:
```
setup ✓
├─ deploy-pi-0 ✓
│ └─ validate-pi-0 ✗ (BLE failed to start)
└─ deploy-pi-1 ✓
└─ validate-pi-1 ✓ (BLE online)
```
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The deploy workflow was failing to start rnsd because the SSH session's
PATH doesn't include ~/.local/bin where rnsd is installed.
Issue:
- rnsd installed at ~/.local/bin/rnsd (pip install --user)
- Non-interactive SSH session doesn't have ~/.local/bin in PATH
- Command "nohup rnsd" failed: "command not found"
- Deployment reported "Failed to start rnsd"
Fix:
- Define RNSD_BIN="$HOME/.local/bin/rnsd"
- Use full path when starting rnsd via nohup
- Works regardless of SSH session PATH configuration
Now deployment will successfully restart rnsd after copying updated files.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The deploy workflow was failing when manually triggered via workflow_dispatch
because it only checked for github.event.workflow_run.head_branch, which is
empty for manual triggers.
Issue:
- Manual trigger: gh workflow run deploy.yml --ref refactor/abstraction-layer
- BRANCH_NAME was empty ("")
- git checkout "" failed: "empty string is not a valid pathspec"
- Deployment failed on all Pis
Fix:
- Use fallback operator: github.event.workflow_run.head_branch || github.ref_name
- workflow_run trigger: uses head_branch (branch that triggered the tests)
- workflow_dispatch trigger: uses ref_name (branch being run on)
Now works for both:
- Automatic deployment after tests complete
- Manual deployment via workflow_dispatch or gh CLI
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Remove GitHub workflow documentation as it was specific to personal infrastructure setup and not relevant for general users of the BLE interface.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Update version to align with BLE Protocol v2.2 implementation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added workflow_dispatch trigger to allow manual deployment without
waiting for test workflow completion. This is useful for:
- Testing the deployment workflow
- Deploying when automatic trigger doesn't fire
- Re-deploying without pushing new code
Usage:
- Go to Actions → Deploy to Raspberry Pi → Run workflow
- Or via CLI: gh workflow run deploy.yml
Updated the if condition to run on either:
- Automatic trigger when tests complete successfully
- Manual trigger via workflow_dispatch
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The branches filter in workflow_run triggers can cause workflow validation
errors: "The workflow must contain at least one job with no dependencies."
According to GitHub Actions documentation, the branches/branches-ignore
filters are not well-supported in workflow_run triggers and can cause
validation issues.
Removed the branches filter - the workflow will now trigger when the
"Tests" workflow completes on any branch, which is the intended behavior.
Fixes workflow validation error on Line 11, Col 3.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Host pre-built dbus_fast wheel on GitHub Releases to significantly speed
up installation on 32-bit ARM devices like Raspberry Pi Zero W.
Changes:
- Created GitHub Release (armv6l-wheels-v1) with dbus_fast 2.44.5 wheel
- Python 3.13 on ARMv6l architecture
- 874KB wheel file saves ~20 minutes of compilation on Pi Zero W
- Release URL: https://github.com/torlando-tech/ble-reticulum/releases/tag/armv6l-wheels-v1
- Modified install.sh to auto-download pre-built wheels:
- Detects Python 3.13 on 32-bit ARM (armhf/armv6l/armv7l)
- Downloads dbus_fast wheel from GitHub Releases
- Falls back gracefully to source build if download fails
- Saves ~20 minutes installation time on Pi Zero W
- Updated README.md with comprehensive documentation:
- Added "Pre-built Wheels for Raspberry Pi Zero W" section
- Documented automatic installation behavior
- Provided manual installation instructions
- Explained why pre-built wheels matter for low-power devices
- Added quick reference in automated installation section
Time savings on Pi Zero W:
- Before: 15-30 minutes (compile dbus_fast C extensions from source)
- After: < 10 seconds (download and install pre-built wheel)
The installer now transparently optimizes for Pi Zero W while maintaining
compatibility with all other platforms.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Updated install.sh to copy the new driver abstraction files
(bluetooth_driver.py and linux_bluetooth_driver.py) that were added
during the driver refactor. These files are required by BLEInterface.py
and were causing import failures in the installer integration test.
Changes:
- Copy bluetooth_driver.py to ~/.reticulum/interfaces/
- Copy linux_bluetooth_driver.py to ~/.reticulum/interfaces/
- Update success message to list the new driver files
Fixes installer test failure:
ModuleNotFoundError: No module named 'bluetooth_driver'
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The v2.2 protocol test suites require full RNS module environment and
cannot run in the current CI setup. Excluded them from integration tests
to prevent import errors.
Changes:
- Added --ignore flags for test_v2_2_*.py files in integration test step
- Updated workflow README to document excluded tests
- Tests remain in repository as specification/documentation
These tests will run when:
1. Integrated into main Reticulum repository (has full RNS module)
2. Local development with proper RNS environment
CI now passes with 107 tests (same as before v2.2 tests were added).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Removed test_refactor_suite.py as it is completely superseded by the
comprehensive test suite:
Reasons for removal:
- Broken: Import errors, cannot run
- Incomplete: Contains TODO comments, no actual assertions
- Overlapped: Functionality covered by test_multi_device_simulation.py
- Inferior: 1 broken test vs 20 passing comprehensive tests
- Wrong approach: Tried to run real BLE instances instead of using mocks
- Already excluded: Ignored in CI via --ignore flag
The multi_device_simulation test suite provides superior coverage:
- MockBLEComponents (5 tests)
- SimulatedBLENode (3 tests)
- TwoDeviceSimulator (6 tests)
- IntegrationScenarios (4 tests)
- Performance (2 tests)
This was leftover scaffolding from the driver abstraction refactor.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Updated tests to reflect the new driver-based architecture where GATT
server and connection management are handled by the driver layer instead
of directly in BLEInterface.
Changes:
- test_integration.py: Updated to check for driver callbacks instead of
old GATT server methods (_data_received_callback vs on_data_received)
- test_integration.py: Added test for driver abstraction layer
- test_prioritization.py: Updated to check for driver.connect() instead
of removed _connect_to_peer() method
All 106 tests now pass (excluding test_refactor_suite.py which has
import issues and appears to be obsolete).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changed from invalid cross-workflow job dependency (needs) to workflow_run
trigger. Deploy now runs after "Tests" workflow completes successfully.
Changes:
- Trigger on workflow_run instead of push
- Only run if test workflow conclusion is success
- Use workflow_run event refs for branch/commit/actor
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Replaced heredoc syntax with a bash variable to avoid YAML parsing issues.
The deployment script is now stored in DEPLOY_SCRIPT variable and piped
to ssh via echo.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changed heredoc delimiter from EOF to DEPLOY_SCRIPT to avoid YAML parsing
issues. Also explicitly pass environment variables to SSH remote command.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implements comprehensive connection state tracking to prevent "Operation
already in progress" errors and connection retry storms.
BLE Interface changes:
- Record connection attempts before calling driver.connect()
- Add 5-second rate limiting between attempts to same peer
- Skip connections already in progress via _connecting_peers check
- Downgrade expected race conditions to DEBUG level
- Auto-blacklist MAC addresses on connection failures
- Add diagnostic logging for concurrent connection tracking
BLE Driver changes:
- Add _connecting_peers set to track in-progress connections
- Prevent concurrent connection attempts to same address
- Attach cleanup callbacks to connection Futures
- Add defense-in-depth cleanup in finally blocks
- Detailed logging for connection state debugging
Documentation updates:
- Add deployment workflow documentation to README.md
- Update .github/workflows/README.md with CD workflow details
- Document containerized runner SSH configuration
- Update reference documentation (CLAUDE.md, BLE_PROTOCOL, etc.)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Adds continuous deployment workflow that automatically deploys code changes
to Raspberry Pi devices after tests pass.
Features:
- Runs on self-hosted runner after unit/integration tests complete
- Supports containerized runners (k3s/Docker) via SSH key secrets
- Deploys to multiple Pis in sequence with detailed logging
- Automatically restarts rnsd service after code update
- Fails entire job if any Pi deployment fails
Required secrets: PI_HOSTS, PI_REPO_PATH, PI_USER, PI_SSH_KEY
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixes "br-connection-canceled" and "Operation already in progress" errors
caused by BlueZ attempting Classic Bluetooth (BR/EDR) instead of BLE (LE).
Problem:
- ConnectDevice() with AddressType="public" forces LE-only connections
- Previously only tried once (has_connect_device is None check)
- After first failure, ALL future connections skipped ConnectDevice()
- Fell back to client.connect() which may trigger BR/EDR on dual-mode adapters
Solution:
- Changed condition from "is None" to "!= False"
- Now retries ConnectDevice() on every connection (unless definitively unavailable)
- Improved error handling:
* AttributeError → method doesn't exist, disable permanently
* Other exceptions → transient failure, retry next time
- Elevated log level to INFO for successful LE connections
Impact:
- Eliminates BR/EDR connection attempts on BLE-only devices
- Fixes immediate disconnects after pairing
- Prevents connection blacklisting due to protocol mismatch
Tested on: Raspberry Pi with BlueZ 5.66 + experimental mode
Fixes "Failed to register advertisement" error (BlueZ error 0x03) caused by
device name exceeding 31-byte BLE advertisement packet limit.
Changes:
- Make device_name optional (default: None) to save advertisement space
- Remove auto-generation of long identity-based names (RNS-{32-hex-identity})
- Update driver to handle None device names when creating peripheral
- Use full 16-byte identity (32 hex chars) for fragmenter keys to avoid collisions
- Update documentation to reflect device name is optional and discovery is UUID-based
Discovery is based on service UUID matching only. Identity is obtained from
the Identity GATT characteristic after connection, not from device name.
Tested on Raspberry Pi Zero W with BlueZ 5.82 - advertisement now registers
successfully (ActiveInstances: 1).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Quick project overview and architecture summary
- Links to key documentation (BLE_PROTOCOL_v2.2.md, README, etc.)
- Development workflow guidance
- File-by-function quick reference
Helps AI assistants quickly orient to the project without duplicating
existing documentation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Problem
The identity handshake handler called `self.driver.get_peer_mtu(address)`,
but this method didn't exist, causing:
```
[Error] BLEInterface[BLE Interface] failed to process identity handshake from dev:B8:27:EB:A8:A7:22: 'LinuxBluetoothDriver' object has no attribute 'get_peer_mtu'
```
## Solution
Added `get_peer_mtu(address)` method to LinuxBluetoothDriver that:
1. Checks central connections (self._peers) for MTU when we're the central
2. Checks peripheral connections (gatt_server.connected_centrals) for MTU when we're the peripheral
3. Returns None if peer not found in either
This mirrors the existing `get_peer_role()` pattern and provides
thread-safe access to MTU information for both connection types.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Problem
After the driver refactor (commit d1d94e5), peripheral devices were dropping
the identity handshake sent by central devices. The logs showed:
```
[Warning] BLEInterface[BLE Interface] no identity for dev:B8:27:EB:A8:A7:22, cannot create fragmenter
[Warning] BLEInterface[BLE Interface] no identity for peer dev:B8:27:EB:A8:A7:22, dropping data
```
Root cause: When the central sends its 16-byte identity handshake, the
peripheral's `_data_received_callback` passed it to `_handle_ble_data`,
which immediately dropped it (chicken-and-egg: no identity = drop data,
but the dropped data IS the identity).
The handshake detection logic existed in commit babb237 but was lost
during the driver architecture refactor.
## Solution
Added `_handle_identity_handshake()` method that:
1. Detects identity handshakes (exactly 16 bytes, no existing identity)
2. Stores the central's identity in bidirectional mappings
3. Creates fragmenter/reassembler with negotiated MTU
4. Spawns peer interface for the central
5. Returns True to prevent normal data processing
Updated `_data_received_callback()` to check for handshakes before
passing data to normal reassembly logic.
## Benefits
- ✅ Restores bidirectional communication for peripheral connections
- ✅ Peripheral can learn central's identity without scanning
- ✅ Clean separation of handshake vs. data processing
- ✅ Proper error handling with informative logging
## Testing
Should resolve the asymmetric identity exchange seen in Pi1/Pi2 logs where
central successfully connected but peripheral couldn't create fragmenter.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Problem
The central device was timing out when trying to read the identity
characteristic from peripheral devices, causing connection failures:
```
ERROR: Error reading characteristic ...28e6 from B8:27:EB:10:28:CD: TimeoutError
```
Root cause: The driver already reads the identity during connection setup
(line 806 in _connect_to_peer), but then BLEInterface tried to read it
AGAIN in _device_connected_callback. The second read consistently timed
out, likely due to BlueZ/D-Bus caching issues or characteristic state.
## Solution
Changed the `on_device_connected` callback signature to pass the peer
identity directly, following the established pattern of other callbacks
like `on_data_received(address, data)` and `on_mtu_negotiated(address, mtu)`.
### Changes
1. **Driver Interface** (bluetooth_driver.py)
- Updated callback: `on_device_connected(str, Optional[bytes])`
- Identity is None for peripheral connections (arrives via handshake)
2. **PeerConnection** (linux_bluetooth_driver.py)
- Added `peer_identity: Optional[bytes]` field
- Store identity read during connection setup
3. **Connection Flow** (linux_bluetooth_driver.py)
- Central: Pass identity to callback after reading it
- Peripheral: Pass None (identity comes later via handshake)
4. **BLEInterface** (BLEInterface.py)
- Updated callback signature to accept peer_identity parameter
- Removed buggy `read_characteristic()` call
- Use passed identity directly for central connections
- Added typing.Optional import
## Benefits
- ✅ Eliminates redundant GATT read operation
- ✅ Fixes timeout bug for central connections
- ✅ More efficient: reuses identity already read by driver
- ✅ Cleaner architecture: follows callback pattern consistency
- ✅ Explicit about identity availability by connection role
## Testing
Tested on Raspberry Pi Zero W devices with BlueZ 5.82:
- Central connections now receive identity immediately
- Peripheral connections correctly wait for handshake
- No more timeout errors
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This commit addresses a timeout issue where a central device would fail
to read the identity characteristic from the peripheral.
The root cause is suspected to be a race condition in the underlying
BlueZ/D-Bus stack, where the `read_callback` for the characteristic
was not firing reliably, causing the central's read request to hang
and time out.
To make this process more robust and less dependent on timing, the
GATT server implementation has been hardened:
1. The identity characteristic is now initialized with a 16-byte
placeholder value. This ensures the D-Bus object is created with
the correct data length from the start.
2. When the asynchronous RNS identity becomes available, the server now
proactively pushes the identity to the characteristic using
`set_value()`. This no longer relies exclusively on the fragile
`read_callback` mechanism.
Additionally, error logging within the driver has been improved to
include the exception type, aiding future diagnostics.
This commit addresses two critical issues that prevented the BLE
interface from functioning correctly after the driver abstraction
refactor.
1. **Fix `exec()` Startup Error:**
The interface failed to load via `rnsd` due to a `KeyError: '__name__'`
caused by using relative imports (`from . import ...`). The `exec()`
environment used by Reticulum does not preserve package context,
breaking these imports. This is fixed by reverting to absolute
imports (`from bluetooth_driver import ...`) which work correctly
with the existing `sys.path` manipulation logic.
2. **Fix Connection Role Logic:**
Connections were failing because the interface would always attempt
to read the peer's identity, even when acting as the peripheral.
This caused a `Can only read characteristics in central mode` error.
The fix introduces role-aware logic into the connection callback:
- A `get_peer_role()` method was added to the driver interface.
- `BLEInterface` now checks the role on connection.
- If central, it reads the identity characteristic.
- If peripheral, it waits for the identity handshake packet,
preventing the invalid operation.
Resolved import conflicts by keeping the updated relative import paths.
Driver files are now correctly located in src/RNS/Interfaces/ instead of
project root.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Implement automatic device name generation from Transport.identity hash
to enable reliable peer discovery when bluezero service_uuid exposure
is unreliable.
Changes:
- Auto-generate device_name as RNS-{32-hex-identity} if not configured
- Parse peer identity from device name pattern (RNS-[0-9a-f]{32})
- Update GATT server device_name before advertising
- Store parsed identities in address_to_identity mapping
Limitations discovered:
- bluezero Peripheral uses system hostname for BLE local_name, not
the device_name parameter we set
- BlueZ D-Bus cache issues cause service_uuid exposure to be unreliable
- Reboot + cache clear (/var/lib/bluetooth/*/cache) temporarily fixes
service_uuid visibility
Current status:
- Bidirectional discovery works via service_uuid after fresh reboot
- Identity parsing infrastructure ready for future manufacturer_data approach
- Fallback to Protocol v1 address-based tracking remains functional
Tested on Raspberry Pi 4 with BlueZ 5.76, bluezero 0.9.1, bleak 1.1.1
Generated with Claude Code (https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Enable BLE peripheral connections to send data by creating fragmenters
in handle_peripheral_data() after identity handshake. Previously,
fragmenters were only created for central connections (_connect_to_peer),
which caused "No fragmenter for peer" warnings when peripheral-only
connections attempted to transmit data.
This fix ensures bidirectional data flow works correctly regardless of
which device initiates the BLE connection, completing the unified
interface architecture.
Impact: Fixes announce rebroadcasting from peripheral-only connections
and enables full mesh networking over BLE.
Tested on Raspberry Pi 4 with BlueZ 5.76.
Generated with Claude Code (https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Critical fix for message delivery and Android MAC rotation support.
**Problem:**
- Fragmenters keyed by MAC address
- Failed with "dev:" prefix mismatch
- Would break on Android MAC rotation
**Solution:**
Use identity_hash for fragmenter/reassembler keys (with Protocol v1 MAC fallback).
**Changes:**
1. Added _get_fragmenter_key() helper - returns identity_hash or normalized MAC
2. Updated _connect_to_peer() - creates fragmenters with identity keys
3. Updated BLEPeerInterface.processOutgoing() - looks up fragmenters with identity keys
**Benefits:**
- ✅ Fixes immediate "No fragmenter" bug
- ✅ Survives Android MAC address rotation
- ✅ Consistent with unified interface architecture
- ✅ One fragmenter per peer identity (not per ephemeral MAC)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
