gatt: Panics when receiving writes with bad length about nrf-softdevice HOT 3 CLOSED

After some testing I can confirm that on pure C code, disabling vlen doesn't prevent variable length received on the server. So this is not a bug, simply a misunderstanding of what vlen does. If the client writes 0 bytes, the received packet is 0 on the server.

Variable length only changes the length of the client when he reads or is notified by the server, not when the server receives data.

I don't know what would be the best way to handle this, but padding with zeroes (while considering endianness) could be an option.

from nrf-softdevice.

Attempting to clarify to any other new user of this crate, because this took me a while running into the issue and finding this:

AIU, the softdevice should already filter out attempts to write outside of the bounds established by this crate. Some interpretation difference between the softdevice and this crate causes issues. At least from this crate's point of view, the many unwrap! calls in gatt_traits.rs are justified, just something about when the size guards should kick in is unclear.

(This doesn't change anything about this being an issue, but the crate authors are not lightly spreading unwraps in paths that are user controlled).

from nrf-softdevice.

I've created a quick fix at #139. Writes with a bad length will be ignored rather than panicking. If more sophisticated handling is needed you can implement the service by hand. Let me know if the PR resolves the issue for you.

from nrf-softdevice.