Hi Johan,
>> + if (cp->val) {
>> + struct hci_cp_write_current_iac_lap cp;
>> +
>> + if (timeout > 0) {
>> + /* Limited discoverable mode */
>
> Wouldn't we want to follow the recommendation from the Core spec here,
> volume 3, part C, section 4.1.2.1:
>
> "A Bluetooth device should not be in limited discoverable mode for more than
> TGAP(104)"
>
> TGAP(104) in turn is defined as 1 minute (vol 3, part C, Appendix A).
I was not going to be this strict. So yes, userspace can violate the GAP part here, but it might be a good idea to ensure that when a too large value is entered we stick with general discoverable mode. However is this really worth it.
Another option is to just reject too large timeout values as invalid parameters and force userspace to implement large timeouts with general discoverable mode in userspace.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
