HostGattService WriteValue doesn't reply to the client

[muneale]

Hi everyone,
firstly I would say thanks for this library, is the only one that I really appreciate in order to create your own GATT service without starting from scratch.

That said, I'm stuck in the implementation of a HTTP Proxy Service (that I can share with you as examples for other people) by following its specification provided by Bluetooth.
Currently I developed a new BaseHostInterface called HttpProxyCharacteristic which can correctly read/notify a value, however when the client asks to write a new value the WriteValue method writes correctly the new value, but doesn't reply anything.

The code for the WriteValue method is the following:

@method({ inSignature: "aya{sv}", outSignature: "" })
WriteValue(value, options) {
  value = this.onWriteValue(value, options);         #Method to elaborate data
  this.Value = [...Buffer.from(value)];              #Value is a property defined in the Gatt Characteristic
  this.emitPropertiesChanged({
    Value: new Variant("ay", [...this.Value]),
  });
}

# Must be overwritten in the characteristic implementation if you want elaborate data 
onWriteValue(value: any, options: any): any { 
  return value;
}

This is also the output when I print the options of the WriteValue method:

{
  device: Variant {
    signature: 'o',
    value: '/org/bluez/hci0/dev_00_00_00_00_00_00'  # The ID is actaully different
  },
  link: Variant { signature: 's', value: 'LE' },
  mtu: Variant { signature: 'q', value: 517 }
}

I'm currently testing it with LightBlue app which states that the write has not been performed correctly (Error 14).
Am I missing something or this is actually a bug?

[QuadratClown]

Sorry for the late reply.

I've encountered the same issue using LightBlue - writing works fine, sent bytes appear on the host side, but LightBlue reports error 14.

The error is related to ATT error 14 "unlikely", which is triggered when the dbus-call for writeValue does not do a method_return. I found a similar issue in another project.

This is whole thing is very unintuitive, since the bluez-doc implies that writeValue is of type void, hence should not require a return value. I suspect this is an issue with dbus-next, but further investigation is required.

I've never encountered this issue personally before, since I implemented both peripheral and server using the same library. For now, there is a workaround: Use "writeWithoutResponse" on the client side.