Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4055243ybl; Tue, 20 Aug 2019 06:24:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqxoITWzWs8cPMQrrP4xcFGU/5mpndR3IOkA4P/EYDX8d8ETWwb7pO89xFNI5g79g1NgWlVU X-Received: by 2002:a17:902:1107:: with SMTP id d7mr27748504pla.184.1566307471465; Tue, 20 Aug 2019 06:24:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566307471; cv=none; d=google.com; s=arc-20160816; b=t04SHQOLPshXGOVh1A5GA6AInduaUP4eyrGGenssxr8TwZSdcfu8cmq0fNuw0VB2UQ 468TtPIgUilVVoW875qkGE3vwfWns0I71hmsZG2x8OlnT16XYfP6ZFe8RuaRKbiLOMbu g3Z2pGfXJKMegslBqDV1oC7ebqlFKhqTfl8CAeoIeAL440A0dkvYvi7+CvYcady9zCCv lTAxy0KZun1kwtVbRrpNjzoZrtDIUtLAhiWnRQTM5otnhu/6eHQx5pi6bZa5r5WsKWPQ Mxb9slQZHR1mfil/8DR5rxRfzqrD9VOFBpdgcShOjTZHwLBbFD2chN+Qlz5iAzYu1zVw dpHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:reply-to:dkim-signature; bh=QQes9DUnXhC73eARxBQoQrmlVOBm48ISTAGez9p7qCY=; b=DhhFnmrPKVijo2g472/rKRCIUxGUfCzQjEQlrYlwCetyuzNPpM01+7k8BDZ+5Wc5We kNSq0o0dX48X2bCXXBDW4yGGM1qZFPKiAPwa8xHbRyTAn5QOH3Dy03yYVbduNKPgsTC1 6FECQnrULDRUiGjts6Ds86mt5cs6/7m0cCObrB6RIwP5S6JrFSVisQeldG+V1/h57fJX hGQ43dVrJEji9fkYdzt0mcMX/152JY9FsPRMt0T4pbKrW/ONp14pHNsEYLj9xVgnpHYh d+XVPM5P59lehwurha2SWYA3TQa2zJigi2SnRrbUagD0fR7Gn1hlUOCGF8kwyOr4tpk9 uO6g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mZHzOOjA; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h189si12258516pge.36.2019.08.20.06.24.02; Tue, 20 Aug 2019 06:24:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mZHzOOjA; spf=pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729409AbfHTNYA (ORCPT + 99 others); Tue, 20 Aug 2019 09:24:00 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:35596 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728248AbfHTNX7 (ORCPT ); Tue, 20 Aug 2019 09:23:59 -0400 Received: by mail-io1-f67.google.com with SMTP id i22so12110132ioh.2 for ; Tue, 20 Aug 2019 06:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=QQes9DUnXhC73eARxBQoQrmlVOBm48ISTAGez9p7qCY=; b=mZHzOOjAEKAq73dT64KmuMkQXqP8N1ka0Z/7JPZ2gAe4VQ9gMCk+9ZqkkdIpQQpQJ9 i5kYssKS4Wsa72nkvvwIsqQzKWK7jWhSGB2JZU8N+Bwfy0x2QKtGkv4cEeA/isRxCN/9 Sg3M8eipg1hl+Cs19sW/g4+s7n83A+JVoJyPNQQ63hT3QgiTHMHK/JXoqdmIfuoLMnCW eyQsgfLnDLAYPv8oLKD9Eak8GIOZUzem9pAL5br8TllWG9YHUaZeQrE2M/3y8ncocdNe xW7l3VrIVY9Sln2yq6CzetRH5sPVOHqHPYXUxluuNokmClhg0AhF95OPNcHtDZKarFBY 8W5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=QQes9DUnXhC73eARxBQoQrmlVOBm48ISTAGez9p7qCY=; b=MxEo5Mo8igeEgKJyRr3jE2eXixepCqrg5piiN43lmNWxypj5XIzee5HeZwt3YgXt8J H1N5WYQBMvfVvCx2jOdWVMYPo4I7UrNtHZ7J7znE98p7L6/jnwCdN6Br31BwhzUSnMQU mRPmyFDVb4ZzoirxFPddm2qswYCJBhfKJdi+OTCM/7CoVfuzIibT7U26y5OnpVpuHwts 0ETD44Ee2pAHG41v4ovmBz8+3GtMEFFDpJ7JigYQGfYjv5Zbx2uWqe4mAsP9szlz4kav Z/fIxY0eQ96bWThdGf84FC6F7HavSTYcFUAG8My/NgOPv8sdzJ/jNsKEO8xxPANT1PKD 6bxQ== X-Gm-Message-State: APjAAAUn1Tgo4uIi4CSdBx6EW7wk3Jzm92Xb35h34Fg6YnGuCSX1ZsvN h3jV9Xn8UWyN8W/BnAXnoOs= X-Received: by 2002:a5d:9945:: with SMTP id v5mr17526182ios.143.1566307437709; Tue, 20 Aug 2019 06:23:57 -0700 (PDT) Received: from [10.1.1.187] ([8.39.228.178]) by smtp.gmail.com with ESMTPSA id p3sm15553089iom.7.2019.08.20.06.23.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Aug 2019 06:23:56 -0700 (PDT) Reply-To: csonsino@gmail.com Subject: Re: [PATCH 1/1] bluetooth: validate BLE connection interval updates To: Jamie Mccrae , Andreas Kemnade Cc: Marcel Holtmann , Johan Hedberg , "linux-bluetooth@vger.kernel.org" , Sasha Levin References: <138296C5-49FA-475D-9618-FC8D241B8823@holtmann.org> <20190815104419.161177fa@kemnade.info> <0cda8242-304e-a073-90d8-63e656e3600c@gmail.com> <20190819180813.04a8e771@kemnade.info> <624153c1-d462-1d6d-ddb2-ac7c03575a2c@gmail.com> From: Carey Sonsino Message-ID: Date: Tue, 20 Aug 2019 07:23:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Jamie, I completely agree that different devices should (and need to) be able to negotiate their own desired connection interval... as long as the connection interval that they want to use is within the bounds that I as a Linux system administrator have allowed my system to operate. Admittedly, the current situation is not good because the default values are 24/40, so without additional modification (which it turns out may not be easy or possible if you don't have debugfs) a device can only negotiate a connection interval between 30ms and 50ms otherwise it will receive a negative/rejection response.  But if we were to change the default values to 6/3200, then any device would be able to negotiate it's own desired connection interval between 7.5ms and 4000ms and additional configuration would be required to restrict that range. I think that if multiple BLE devices were connected to my Linux machine, the BLE radio would have to "wake up" on the schedule of the shortest connection interval, so I'm not convinced that you would actually get any benefit from a min/max per client.  But I do agree that I like having that level of control.  If we did want to support a min/max per client, information is already stored per-client in /var/lib/bluetooth// (for secure keys and other things) and we could probably add min/max configuration down there somewhere.  Maybe it could even just override the global min/max in the debugfs area. But also please note that the patch in question does not know or care how the current connection's interval was configured.  It could be from a global setting, or it could be device-specific configuration.  All it knows is that the current connection has min/max values, and if the remote device requests to change the connection interval, the requested value should be checked against the min/max bounds of that connection. If the desired behavior were for Linux to blindly accept and return a successful response for any connection interval change request value, then it makes no sense to have a min/max at all. The min/max would essentially be any value allowed by the bluetooth spec, and having the notion of a min/max connection interval is confusing and misleading.  I believe that if you have bounds defined, then values should be checked against those bounds. Regards, Carey On 8/20/19 12:45 AM, Jamie Mccrae wrote: > Hi, > From my many years' experience of embedded Bluetooth LE development I > would say that offering different connection intervals to different > devices is a must. If you have 3 devices connected to a laptop, for > example 1 device in DFU mode, 1 keyboard and 1 temperature sensor, you > would want vastly different connection interval settings for all of > these. To speed up a firmware update process on the DFU device you would > want the lowest connection interval (and I can speak from experience > having seen an embedded linux SoC try to update a device over DFU via > Bluetooth LE on Bluez 4.x and DBUS that it took in excess of 30 minutes > per device, compared to 1 minute on an android phone). They keyboard is > likely to negotiate a slave latency so that it can stay idle if no keys > are pressed for many connection intervals but if something is > pressed then it can respond fast, and the temperature sensor is going to > have a much larger connection interval, if the sensor itself gathers a > new reading every minute, then a connection interval of 30 seconds would > be fine. So to make things easy for both developers and users, how would > you go about doing that? Simply having a single 'minimum' and 'maximum' > connection interval in a file or hard-coded is not a workable solution > and does nothing to help user experience. > Thanks, > Jamie > >> Andreas, >> >> Considering that this patch has already made it's way into stable trees, >> and the only options are to back it out or to patch it again, I would >> obviously prefer to keep it in and patch it again. I think that it >> would be fairly quick and painless to just set the default min/max to >> 6/3200, or add an additional flag as you suggested, which should resolve >> any problems in the near term. >> >> Longer term, I think that there are several ways to allow the system >> admin to configure the allowable min/max, but it only matters if the >> system will check requests against the configured min/max and respond >> appropriately, which is what the patch in question does. The best >> current way that I'm aware of to control the system-wide connection >> interval is through the existing debugfs mechanism, and in my opinion it >> didn't work correctly without this patch. >> >> Regarding power consumption, I have not done any power measurement >> testing to determine the effect of connection interval on power >> consumption, so perhaps that was not the best use case. Here is the >> exact real world use case that caused me to write the patch in the first >> place: >> >> I was writing a Linux-based test system for an embedded >> BLE-communication based product. The product embedded code was written >> to attempt to renegotiate the connection interval to a fairly low number >> after the initial connection was established. My test system had a >> requirement to be able to perform the tests using various pre-defined >> connection intervals so that I could gather data throughput and product >> performance metrics. Every time my test system attempted to perform a >> test a the desired connection interval, the device would immediately >> request to renegiate to a lower value. Linux would accept that request >> and return a successful response, and I had no way to stop it. Let's >> not go down the "Why didn't you just change the embedded code?" / "Why >> doesn't Linux reject values outside of the configured bounds?" rabbit >> hole... :) >> >> Carey >> >> On 8/19/19 10:08 AM, Andreas Kemnade wrote: >>> Hi Carey, >>> >>> On Mon, 19 Aug 2019 07:58:19 -0600 >>> Carey Sonsino wrote: >>> >>>> This seems like the exact "downside" situation that I described in the >>>> patch writeup. >>>> >>>> I would still claim that as a Linux system administrator, I should have >>>> control over my system. If I am operating in a low power environment, I >>>> do not want to allow a remote device to apply a setting which causes me >>>> to use more power without any say in the matter. >>>> >>> In principle I agree here. High connection interval has its downsides, >>> low connection interval also. Just curios: What are the numbers about >>> power consumption here? A few mA? I have only compared these values on >>> peripherals running on low-power SoCs like e.g. the nrf stuff from nordic. >>> I see around 1 mA difference there with a power consumption besides of that >>> usually measured in the µA range. Never tested these things on a linux machine. >>> >>> The point here is that with this patch there is insufficient control >>> about this. Yes, there is the debugfs interface. >>> >>> But if you want to provide a driver to a gatt service living on top of >>> bluetoothd dbus api? Ask people to not use distribution kernels? >>> What options do you have? >>> using the monitor interface to sniff the connection handle and then >>> call hci_le_conn_update() to set things? >>> >>>> The connection min/max interval settings are configuration options that >>>> control how my bluetooth device operates. Why are these down in debugfs >>>> anyway? I think that a much more appropriate fix would be to migrate >>>> some of the BLE configuration options to sysconfdir (some place like >>>> /etc/bluetooth/ble.conf). That would also help in the persistence of >>>> these configuration settings, which is kind of a pain with the debugfs >>>> mechanism that gets wiped out and recreated on bootup. >>>> >>> I think that these things should be part of the dbus api provided >>> by bluetoothd so that a driver could decide and having defaults outside >>> of such a dark corner like the debug fs. >>> >>>> A quicker fix would be to simply set the default connection min interval >>>> and connection max interval values to the full range (6, 3200). >>> Or just maybe a flag allowing such behavior? >>> >>>> *think* that this could be done by simply updating the values in >>>> hci_core.c, the hci_alloc_dev() function: >>>> >>>> hdev->le_conn_min_interval = 0x0018; >>>> hdev->le_conn_max_interval = 0x0028; >>>> >>>> would become: >>>> >>>> hdev->le_conn_min_interval = 0x0006; >>>> hdev->le_conn_max_interval = 0x0c80; >>>> >>>> This should allow all devices to negotiate whatever connection interval >>>> they want by default. If I'm running on a device with debugfs (which I >>>> happen to be most of the time), then I can still override these defaults >>>> to control my system. >>>> >>>> Please let me know if you would like me to do any further work towards >>>> resolving this issue. I'd be happy to test and submit a patch that >>>> changes the default connection min/max interval values- I could probably >>>> get that done in the next day or two. If you would like me to >>>> investigate migrating configuration settings to /etc then I'd be happy >>>> to do that as well, but it might take a bit more effort and time. >>>> >>> Well, all these things are important, but are new features but there is a >>> problem: >>> The kernel patch has gone into the stable trees and from there into distributions, >>> so how can these new features flow down the same path. >>> >>> Regards, >>> Andreas >>>