Two second pending connection timeout prevents connection to devices with long advertising interval

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We are currently working with a BLE device which (for power consumption reasons) uses an unusually large advertisement period of ten seconds (unusual, but allowed within the BLE specification). We don’t have the option of reducing the advertising interval for this product.

This works with older kernels (e.g. 4.2.6 in RH F23), but on later kernels it appears that the kernel times out the connection attempt after only two seconds.

I believe I have tracked down the change responsible to a patch from Johan Hedberg <johan.hedberg@xxxxxxxxx> on 2014-07-06, which appears to split the BLE connection timeout in to two variants, HCI_LE_CONN_TIMEOUT which remains at 20 seconds, and the newly added one, HCI_LE_AUTOCONN_TIMEOUT, which has been reduced down to two seconds. 

I understand, from other threads touching on this subject (see links below - I am at least not the only person to have hit this problem) that this 2s timeout is chosen to avoid blocking other connections, and agree that the average user probably doesn’t need to be able to handle such slow devices. However, is there any reason why this timeout is hardcoded in the source rather than a tuneable parameter, which would at least allow those of us who do need to interact with such devices to be able to configure the linux bluetooth stack suitably.

Personally, I would regard a change which prevents interoperability with a conformant device as a regression, but I can see why it was done, and why it isn’t an issue for the vast majority of users and devices.

This is my third attempt to raise this issue on the list - I would appreciate if someone could please explain what more I need to do to actually get a response (or even some progress) on this issue?

Thread discussing identical issue with slow advertising device (no apparent solution though):

<http://marc.info/?l=linux-bluetooth&m=146361213623520&w=2>

Thread referenced from above which states why the 2s timeout is expected behaviour:

<http://marc.info/?l=linux-bluetooth&m=144830298701744&w=2>

Regards

Stu

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux