linux-kernel - Re: [PATCH 2/2] bluetooth: raise HCI_CMD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 May 2014 07:35:49 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Luiz Augusto von Dentz <luiz.dentz@...il.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
	Marcel Holtmann <marcel@...tmann.org>,
	Gustavo Padovan <gustavo@...ovan.org>,
	Johan Hedberg <johan.hedberg@...il.com>
Subject: Re: [PATCH 2/2] bluetooth: raise HCI_CMD_TIMEOUT from 2s to 8s

Am 15.05.2014 17:19, schrieb Alexander Holler:
> Am 15.05.2014 16:50, schrieb Alexander Holler:
>> Am 15.05.2014 14:54, schrieb Luiz Augusto von Dentz:
>
>>> This timeout seems arbitrary so I suppose we can increase it if we
>>> feel it is necessary but we used already different timeout for
>>> different commands like HCI_POWER_OFF_TIMEOUT, so perhaps if we can
>>> identify which command is more likely to timeout.
>>>
>>> We could perhaps auto reset if a command timeout if there is really no
>>> other way to recover.
>>
>> It is arbitrary but 2s is not enough here. And as I've written in the
>> description, there is absolutely no reason to keep this timeout
>> unnecessarily short. No one cares if an error message appears after 2s
>> or 8s if the communication with the dongle is in both cases broken
>> afterwards.
>>
>> One of the commands I experieced the problem with was e.g.
>> HCI_OP_DELETE_STORED_LINK_KEY or HCI_OP_WRITE_SSP_MODE.
>
> The problem is that you can never be sure what the origin of a timeouted
> command was. It might have been e.g. the USB-subsystem through wich the
> command and the response has to travel (in case of USB dongles) and not
> the dongle itself.

To explain a bit more, the box I'm experiencing these problems boots 
from USB2.0 HD. So it's likely that there is quiet some action on the 
bus and that shouldn't affect the operation of the BT-stack (besides 
slowing it maybe a bit down).

Regards,

Alexander Holler

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/