write_without_response Characteristic Property Not Exposed to Clients

[mentarus]

Bug Report: write_without_response Characteristic Property Not Exposed to Clients

Summary

The write_without_response attribute is accepted by the #[characteristic] macro but the corresponding BLE property flag (0x04) is not exposed to BLE clients, preventing them from using WriteWithoutResponse operations.

Environment

• trouble-host version: 0.5.1
• Platform: ESP32 (original, not S3/C3)
• Rust version: 1.80+

Expected Behavior

When a characteristic is defined with write_without_response:

#[characteristic(uuid = "a1b2c3d4-e5f6-4a5b-8c9d-0e1f2a3b4c5d", write_without_response, notify, value = [0u8; 128])]
data: [u8; 128],

The BLE client should see characteristic properties including the 0x04 flag:

• Expected: 0x14 (0x04 WriteWithoutResponse + 0x10 Notify)

Actual Behavior

BLE clients see properties 0x1A:

• 0x02 = Read
• 0x08 = Write (with response)
• 0x10 = Notify
• Missing: 0x04 = Write Without Response

This causes iOS CoreBluetooth to reject WriteWithoutResponse operations:

WARNING: Characteristic does not specify the "Write Without Response" property - ignoring response-less write

Steps to Reproduce

1. Define a GATT characteristic with write_without_response property
2. Connect from iOS/Android BLE client
3. Inspect characteristic properties
4. Attempt to write without response
5. Client rejects the operation due to missing property flag

Root Cause Analysis

The host-macros/src/characteristic.rs parser correctly recognizes write_without_response as a valid property. However, the macro code generation does not properly include CharacteristicProp::WriteWithoutResponse (0x04) in the properties array passed to the GATT table builder.

The CharacteristicProp enum in host/src/attribute.rs correctly defines:

WriteWithoutResponse = 0x04,

But the macro-generated code is not including this property when building the characteristic.

Proposed Fix

The macro code needs to generate CharacteristicProp::WriteWithoutResponse in the props array when the write_without_response attribute is present.

Workaround

None currently available. Clients requiring WriteWithoutResponse cannot communicate with trouble-host GATT servers.

Impact

• Severity: High
• Affected use cases: Any protocol requiring WriteWithoutResponse for low-latency, high-throughput BLE communication
• Blocks: BitChat mesh networking implementation on ESP32

Additional Context

Tested with multiple characteristic property combinations:

• read, write, write_without_response, notify → properties = 0x1A (missing 0x04)
• write_without_response, notify → properties = 0x1A (missing 0x04)
• write, notify → properties = 0x1A (correct, no WriteWithoutResponse expected)

The issue is consistent across all combinations including write_without_response.

[mentarus]

Investigation Results

Code analysis of trouble-host v0.5.1 shows:

1. ✅ Macro parsing (host-macros/src/characteristic.rs:135) - correctly recognizes write_without_response
2. ✅ Macro code generation (host-macros/src/service.rs:318-322) - correctly includes CharacteristicProp::WriteWithoutResponse in props array
3. ✅ Expanded macro output - verified generates &[CharacteristicProp::WriteWithoutResponse, CharacteristicProp::Notify]
4. ✅ From implementation (host/src/attribute.rs:864-874) - correctly OR-s property values
5. ✅ Declaration encoding (host/src/attribute.rs:191-194) - correctly writes props.0

CONFIRMED: Bug is NOT in trouble-host!

Runtime testing with forced property values:

• Test 1: Forced CharacteristicProps::from() to return 0x14 when receiving 0x1A → iOS still saw 0x1A
• Test 2: Forced Declaration::read() to write 0x14 instead of props.0 → iOS still saw 0x1A

Conclusion: trouble-host correctly writes 0x14 (WriteWithoutResponse | Notify) but iOS receives 0x1A (Read | Write | Notify). The properties byte is being modified by a layer below trouble-host.

Root Cause: The bug is in esp-radio or ESP32 BLE controller firmware, not in trouble-host.