From 857c0b8145c81929807dcdcd4c5eef8a91516a14 Mon Sep 17 00:00:00 2001 From: torlando-tech Date: Sat, 15 Nov 2025 22:45:47 -0500 Subject: [PATCH] chore: prepare v0.2.2 release MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Update CHANGELOG.md with release notes for v0.2.2 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude --- CHANGELOG.md | 68 ++++++++++++++++------------------------------------ 1 file changed, 20 insertions(+), 48 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index d882b02..6e1c8b7 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -7,56 +7,28 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ## [Unreleased] +## [0.2.2] - 2025-11-15 + +### Added +- pipx installation support with automated D-Bus dependency handling +- BlueZ LE-only mode configuration in installer (prevents BR/EDR fallback) +- Scanner watchdog to detect and recover from Bluetooth stack corruption +- Service UUID filtering for more efficient peer discovery +- Pre-built wheel support for Pi Zero W Python 3.13 (saves 20+ min install time) + ### Fixed -- **Connection race condition causing "Operation already in progress" errors** - - Added `_connecting_peers` state tracking in `linux_bluetooth_driver.py` to prevent concurrent connection attempts to the same peer - - Implemented 5-second connection attempt rate limiting per peer in `BLEInterface.py` - - Added pending connection check in peer selection logic - - Downgraded expected race condition errors from ERROR to DEBUG level to reduce log noise - - Prevents false-positive peer blacklisting from benign concurrent connection attempts - - Improves connection success rate by approximately 15-20% in high-density environments - - Files: `src/RNS/Interfaces/linux_bluetooth_driver.py`, `src/RNS/Interfaces/BLEInterface.py` +- Connection race conditions from concurrent connection attempts to the same peer +- BlueZ D-Bus state corruption after connection timeouts/failures - devices can now reconnect after blacklist period +- Scanner interference causing "Operation already in progress" during connections +- GATT server race where services weren't available on D-Bus before first connection attempt +- D-Bus disconnect monitoring switched to ObjectManager with polling fallback +- Peripheral disconnect cleanup preventing new connections after hitting peer limit +- Identity mapping cleanup on disconnect (prevents stale peer tracking) +- RSSI sentinel value filtering (-127 from BlueZ) +- Columba Android compatibility (filter 1-byte keepalive packets) -- **BlueZ state corruption causing persistent "Operation already in progress" errors** - - Added explicit `client.disconnect()` in timeout and failure exception handlers - - Implemented `_remove_bluez_device()` method to remove stale D-Bus device objects via BlueZ `RemoveDevice()` API - - Integrated BlueZ device cleanup after connection timeouts, failures, and peer blacklisting - - Prevents BlueZ from maintaining stale connection state after abandoned connection attempts - - Enables successful reconnection after blacklist period expires - - Fixes issue where devices could not reconnect after multiple failed attempts due to corrupted BlueZ state - - Files: `src/RNS/Interfaces/linux_bluetooth_driver.py` (lines 786-830, 980-1069), `src/RNS/Interfaces/BLEInterface.py` (lines 1475-1490) - -- **Scanner interference causing "Operation already in progress" errors during connection attempts** - - Added `_should_pause_scanning()` method to check for active connections before starting scanner - - Modified `_perform_scan()` to skip scan cycle when connections are in progress - - Scanner automatically pauses when `_connecting_peers` is not empty - - Scanner automatically resumes when connections complete - - Prevents BlueZ "InProgress" errors from scanner.start() conflicting with connection operations - - Improves connection reliability by eliminating scan-induced connection failures - - Reduces BlueZ error log spam from scan loop - - Files: `src/RNS/Interfaces/linux_bluetooth_driver.py` (lines 539-551, 586-588) - - Tests: `tests/test_scanner_connection_coordination.py` - -- **BR/EDR fallback - clarify ConnectDevice() object path return as success** - - Modified `_connect_via_dbus_le()` to capture and log object path returned by ConnectDevice() - - Object path (D-Bus signature 'o') indicates successful LE connection initiation - - Prevents confusion from "br-connection-profile-unavailable" error messages - - Some BlueZ versions report BR/EDR profile unavailable while LE connection succeeds - this is expected - - Improved logging shows object path for debugging visibility - - Clarifies that object path return means success, not error - - Files: `src/RNS/Interfaces/linux_bluetooth_driver.py` (lines 1121-1132) - - Tests: `tests/test_breddr_fallback_prevention.py` - -- **GATT server initialization race causing "Reticulum service not found" errors** - - Added `_verify_services_on_dbus()` method to poll D-Bus for service availability after server start - - Fixed race condition where `started_event` fires before `peripheral.publish()` exports services to D-Bus - - Polls D-Bus adapter introspection every 200ms with 5-second timeout - - Ensures services are actually exported before accepting central connections - - Eliminates "service not found" errors during server startup window (typically 50-200ms) - - Graceful degradation: warns if verification times out but doesn't fail startup - - Typical verification time: 100-300ms, no runtime performance impact - - Files: `src/RNS/Interfaces/linux_bluetooth_driver.py` (lines 1493-1559, 1527-1538) - - Tests: `tests/test_gatt_server_readiness.py` +### Changed +- Refactored to driver-based architecture (future Windows/macOS/Android support) ## [0.1.1] - 2025-11-10