Resolved conflicts:
- BLEInterface.py, test_v2_2_mac_sorting.py, CLAUDE.md: Keep release
(HW_MTU fix, pending_mtu, MAC rotation recovery/bypass, corrected tests)
- install.sh, README.md: Keep main (JustWorksRepairing auto-configuration)
- CHANGELOG.md: Consolidated detailed notes from main into [0.2.2] section
- Added FUNDING.yml from main
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Update CHANGELOG.md with release notes for v0.2.2
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixed race condition where started_event fires before peripheral.publish()
fully exports GATT services to D-Bus, causing "Reticulum service not found"
errors when central devices connect immediately after server startup.
Root cause:
- started_event.set() called on line 1665
- peripheral_obj.publish() called on line 1669 (exports to D-Bus)
- 50-200ms gap where server thinks it's ready but services aren't on D-Bus yet
- Central connects during gap -> "service not found" error
Fix:
- Added _verify_services_on_dbus() method to poll D-Bus adapter introspection
- Polls every 200ms with 5-second timeout after started_event fires
- Only returns from start() after confirming services are exported
- Graceful degradation: warns on timeout but doesn't fail startup
Impact:
- Eliminates "service not found" errors during server startup
- Ensures services are actually available before accepting connections
- Typical verification time: 100-300ms
- No runtime performance impact (only affects startup)
Files changed:
- src/RNS/Interfaces/linux_bluetooth_driver.py: Add D-Bus polling
- tests/test_gatt_server_readiness.py: Add test coverage
- BLE_PROTOCOL_v2.2.md: Document initialization race fix
- CHANGELOG.md: Record fix details
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Fixed race condition where started_event fires before peripheral.publish()
fully exports GATT services to D-Bus, causing "Reticulum service not found"
errors when central devices connect immediately after server startup.
Root cause:
- started_event.set() called on line 1665
- peripheral_obj.publish() called on line 1669 (exports to D-Bus)
- 50-200ms gap where server thinks it's ready but services aren't on D-Bus yet
- Central connects during gap -> "service not found" error
Fix:
- Added _verify_services_on_dbus() method to poll D-Bus adapter introspection
- Polls every 200ms with 5-second timeout after started_event fires
- Only returns from start() after confirming services are exported
- Graceful degradation: warns on timeout but doesn't fail startup
Impact:
- Eliminates "service not found" errors during server startup
- Ensures services are actually available before accepting connections
- Typical verification time: 100-300ms
- No runtime performance impact (only affects startup)
Files changed:
- src/RNS/Interfaces/linux_bluetooth_driver.py: Add D-Bus polling
- tests/test_gatt_server_readiness.py: Add test coverage
- BLE_PROTOCOL_v2.2.md: Document initialization race fix
- CHANGELOG.md: Record fix details
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
ConnectDevice() D-Bus method returns an object path (signature 'o') which
should be treated as success, not error. Previously, the return value was
not captured or logged, causing confusion when error messages like
"br-connection-profile-unavailable" appeared (which is expected for LE-only
connections).
Changes:
- Capture object path returned by call_connect_device()
- Log object path for debugging visibility
- Document that object path indicates successful LE connection initiation
- Clarify that BR/EDR profile unavailable is expected for BLE-only connections
Impact:
- Eliminates confusion from "profile unavailable" error messages
- Confirms LE connection was successfully initiated
- Improved debugging visibility through object path logging
Files changed:
- src/RNS/Interfaces/linux_bluetooth_driver.py: Capture and log object path
- tests/test_breddr_fallback_prevention.py: Add test coverage
- BLE_PROTOCOL_v2.2.md: Document object path behavior
- CHANGELOG.md: Record fix details
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
ConnectDevice() D-Bus method returns an object path (signature 'o') which
should be treated as success, not error. Previously, the return value was
not captured or logged, causing confusion when error messages like
"br-connection-profile-unavailable" appeared (which is expected for LE-only
connections).
Changes:
- Capture object path returned by call_connect_device()
- Log object path for debugging visibility
- Document that object path indicates successful LE connection initiation
- Clarify that BR/EDR profile unavailable is expected for BLE-only connections
Impact:
- Eliminates confusion from "profile unavailable" error messages
- Confirms LE connection was successfully initiated
- Improved debugging visibility through object path logging
Files changed:
- src/RNS/Interfaces/linux_bluetooth_driver.py: Capture and log object path
- tests/test_breddr_fallback_prevention.py: Add test coverage
- BLE_PROTOCOL_v2.2.md: Document object path behavior
- CHANGELOG.md: Record fix details
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Remove inaccurate release dates from unreleased versions.
Only v0.1.1 has an actual release date (2025-11-10).
Changes:
- [0.1.0]: Never released, marked as Unreleased
- [2.2.0]: Not yet released, marked as Unreleased
- [2.1.0]: Not yet released, marked as Unreleased
- [0.1.1]: Keep actual release date (2025-11-10)
Dates will be added when versions are actually released.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Remove inaccurate release dates from unreleased versions.
Only v0.1.1 has an actual release date (2025-11-10).
Changes:
- [0.1.0]: Never released, marked as Unreleased
- [2.2.0]: Not yet released, marked as Unreleased
- [2.1.0]: Not yet released, marked as Unreleased
- [0.1.1]: Keep actual release date (2025-11-10)
Dates will be added when versions are actually released.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Resolve merge conflicts by:
- Keeping version 0.2.2 from refactor branch (next release)
- Using fixed gh CLI release workflow from main (atomic release creation)
- Merging CHANGELOG histories: installer releases (0.1.x) and protocol work (2.x)
Conflicts resolved:
- .github/workflows/release.yml: Use gh CLI for atomic releases
- CHANGELOG.md: Merged both release histories chronologically
- pyproject.toml: Keep 0.2.2 for next refactor release
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Resolve merge conflicts by:
- Keeping version 0.2.2 from refactor branch (next release)
- Using fixed gh CLI release workflow from main (atomic release creation)
- Merging CHANGELOG histories: installer releases (0.1.x) and protocol work (2.x)
Conflicts resolved:
- .github/workflows/release.yml: Use gh CLI for atomic releases
- CHANGELOG.md: Merged both release histories chronologically
- pyproject.toml: Keep 0.2.2 for next refactor release
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Bump version to test fixed release workflow with atomic release creation.
Changes:
- Update pyproject.toml version from 0.1.0 to 0.1.1
- Add CHANGELOG entry documenting release workflow fix
This allows testing the corrected workflow (gh release create) without
being blocked by v0.1.0 tag recreation restrictions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Bump version to test fixed release workflow with atomic release creation.
Changes:
- Update pyproject.toml version from 0.1.0 to 0.1.1
- Add CHANGELOG entry documenting release workflow fix
This allows testing the corrected workflow (gh release create) without
being blocked by v0.1.0 tag recreation restrictions.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add Python packaging and automated release workflow to enable
versioned releases of the BLE interface.
Changes:
- Add pyproject.toml with package metadata and dependencies
- Add GitHub Actions release workflow with validation and artifact generation
- Add CHANGELOG.md documenting v0.1.0 installation system features
The release workflow validates version consistency, runs tests,
generates release artifacts (installer, config, source tarball),
and creates GitHub releases automatically from git tags.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add Python packaging and automated release workflow to enable
versioned releases of the BLE interface.
Changes:
- Add pyproject.toml with package metadata and dependencies
- Add GitHub Actions release workflow with validation and artifact generation
- Add CHANGELOG.md documenting v0.1.0 installation system features
The release workflow validates version consistency, runs tests,
generates release artifacts (installer, config, source tarball),
and creates GitHub releases automatically from git tags.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
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>
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>
