Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp3486339pxv; Mon, 19 Jul 2021 01:01:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwhhoyEO81uDEMVrySyymg3+8XaUPMW4UbnYkTempAEcWrDJ1/SlTwQSGDgRv3u/b6AFP9 X-Received: by 2002:a92:ddc3:: with SMTP id d3mr16722095ilr.190.1626681687734; Mon, 19 Jul 2021 01:01:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626681687; cv=none; d=google.com; s=arc-20160816; b=IC9cpJfI/3vHgzF2uhiP/BQiUwSjbtFZpESOnskLCggbYN2O/KAQnOercxLbmJvCsE Wdusy61LfMvuwEig2UURdfQH0wpETfNEYSm/PakfcOIrPvTf+iymN85sP4q1Zx5Yzys6 e2YSynMabP87IXs2p6kNeOIDLU/XgZlykMh9uo/5Yr0P0C4p0GbAqY0fxtZkJ9iwdE30 x1L0QsZNRpZ6d9pZGTuaosOG6OC8bm1MI8xblNdj07baUbkMEeq53rYakzuS4HBmllGR thxNGiza1OmjGvFDAu6iIfj5nE13yAraHhPZtA9NpWtThJLP4+PqsGpC/ODtezVZag3u wPKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=BhAKxy/4X0oI5+DxK9kEqowoAlBBjXY9KcYhwGcqIpo=; b=InRLEPZqsffjzhvrRnxeCuQOIp0xnUyegsJgLgFafFFH7H6UkFPdW1rQYWlWv7JI8a 06GTGxsSvk0QgYdpbN0Le5si8mr9UVY7cXLh8Y19bPoSu8wjgon/sdGm3DcM6A5XCHC3 7AYHzWaiA5Lj07zKEDp0t9TXPtrz7GVyxJoZF9qRuZtnF5UO23VyYjTkcM60t75nJdRb 2oKXkJVx3iKZhcTtwSb1ZDaXdsJQ9m3PIXSUE4zk8avlGhKT433BodMWSeHk94gEkeJ+ fua5d/FAvnlkErG1+ODqOCOTEbRd1ewZsXxqSzvM/CjWmdY68HqI5fLIpUte5b5u8Yv2 FHjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q10si22866703ilu.60.2021.07.19.01.01.00; Mon, 19 Jul 2021 01:01:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235207AbhGSIBO convert rfc822-to-8bit (ORCPT + 99 others); Mon, 19 Jul 2021 04:01:14 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:44818 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235150AbhGSIBL (ORCPT ); Mon, 19 Jul 2021 04:01:11 -0400 Received: from smtpclient.apple (p5b3d2eb8.dip0.t-ipconnect.de [91.61.46.184]) by mail.holtmann.org (Postfix) with ESMTPSA id 5A369CECF8; Mon, 19 Jul 2021 09:57:47 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: [BlueZ PATCH v2 1/3] error: BR/EDR and LE connection failure reasons From: Marcel Holtmann In-Reply-To: Date: Mon, 19 Jul 2021 09:57:46 +0200 Cc: Bluetooth Kernel Mailing List , Luiz Augusto von Dentz , Alain Michaud , Howard Chung Content-Transfer-Encoding: 8BIT Message-Id: References: <20210626052152.2543526-1-mcchou@chromium.org> <20210625222111.BlueZ.v2.1.If79c3f0720cc893be1770c6853fe2fbe626f2caa@changeid> <086ED9D7-96E6-46AB-88B6-F2E71ACD1B15@holtmann.org> To: Miao-chen Chou X-Mailer: Apple Mail (2.3654.100.0.2.22) Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Miao-chen, >>> The source of Connect() failures can be divided into the following >>> three. >>> - bluetoothd's device interface state transition and profile state >>> transition >>> - Kernel's L2CAP layer state transition >>> - Potential HCI error codes returned by the remote device >>> >>> This also added error-code.txt to describe these error codes. >>> >>> Reviewed-by: Alain Michaud >>> Reviewed-by: Howard Chung >>> --- >>> >>> Changes in v2: >>> - Add error-code.txt >>> - Remove BtdError from return string >>> >>> doc/error-code.txt | 266 +++++++++++++++++++++++++++++++++++++++++++++ >>> src/error.c | 111 +++++++++++++++++++ >>> src/error.h | 52 +++++++++ >>> 3 files changed, 429 insertions(+) >>> create mode 100644 doc/error-code.txt >> >> please split documentation and code changes into separate patches. >> >> >>> >>> diff --git a/doc/error-code.txt b/doc/error-code.txt >>> new file mode 100644 >>> index 000000000..e91324855 >>> --- /dev/null >>> +++ b/doc/error-code.txt >>> @@ -0,0 +1,266 @@ >>> +D-Bus Method Return Error Codes >>> +=============================== >>> + >>> +The motivation of having detailed error codes is to provide context-based >>> +failure reasons along with D-Bus method return so that D-Bus clients can >>> +build metrics and optimize their application based on these failure reasons. >>> +For instance, a client can build retry mechanism for a connection failure or >>> +improve the bottleneck of use scenario based on actionable metrics. >>> + >>> +These error codes are context-based but not necessarily tied to interface or >>> +method calls. For instance, if a pairing request failed due to connection >>> +failure, connection error would be attached to the method return of Pair(). >>> + >>> +BR/EDR connection already connected >>> +=================================== >>> + code: 0x0001 >>> + errno: EALREADY, EISCONN >> >> I would rather see connnection-already-connected instead of 0x0001 in the D-Bus error message. > Having a code attached instead of a string description makes it easier > for a D-Bus client to interpret and map to corresponding handlers IMO. > For instead, a client can simplily use the code in a switch case to > perform retry or error reporting. this argument has been made since forever. However D-Bus is heavily string based and we also have our API heavily string and descriptive. So I rather keep it that way. >> >>> + >>> +Either the profile is already connected or ACL connection is in place. >>> + >>> +BR/EDR connection page timeout >>> +============================== >>> + code: 0x0002 >>> + errno: EHOSTDOWN >>> + >>> +Failed due to page timeout. >>> + >>> +BR/EDR connection profile unavailable >>> +===================================== >>> + code: 0x0003 >>> + errno: ENOPROTOOPT >>> + >>> +Failed to find connectable services or the target service. >>> + >>> +BR/EDR connection SDP search >>> +============================ >>> + code: 0x0004 >>> + errno: none >>> + >>> +Failed to complete the SDP search. >>> + >>> +BR/EDR connection create socket >>> +=============================== >>> + code: 0x0005 >>> + errno: EIO >>> + >>> +Failed to create or connect to BT IO socket. This can also indicate hardware >>> +failure in the controller. >>> + >>> +BR/EDR connection invalid arguments >>> +=================================== >>> + code: 0x0006 >>> + errno: EHOSTUNREACH >>> + >>> +Failed due to invalid arguments. >>> + >>> +BR/EDR connection not powered >>> +============================= >>> + code: 0x0007 >>> + errno: EHOSTUNREACH >>> + >>> +Failed due to adapter not powered. >>> + >>> +BR/EDR connection not supported >>> +=============================== >>> + code: 0x0008 >>> + errno: EOPNOTSUPP, EPROTONOSUPPORT >>> + >>> +Failed due to unsupported state transition of L2CAP channel or other features >>> +either by the local host or the remote. >>> + >>> +BR/EDR connection bad socket >>> +============================ >>> + code: 0x0009 >>> + errno: EBADFD >>> + >>> +Failed due to the socket is in bad state. >>> + >>> +BR/EDR connection memory allocation >>> +=================================== >>> + code: 0x000A >>> + errno: EBADFD >>> + >>> +Failed to allocate memory in either host stack or controller. >> >> If this happens, then the code is wrong. Should be an ENOMEM. > My mistake, this should be ENOMEM. Corrected in v3. >> >>> + >>> +BR/EDR connection busy >>> +====================== >>> + code: 0x000B >>> + errno: EBUSY >>> + >>> +Failed due to other ongoing operations, such as pairing, busy L2CAP channel or >>> +the operation disallowed by the controller. >>> + >>> +BR/EDR connection concurrent connection limit >>> +============================================= >>> + code: 0x000C >>> + errno: EMLINK >>> + >>> +Failed due to reaching the concurrent connection limit to a device. >>> + >>> +BR/EDR connection timeout >>> +========================= >>> + code: 0x000D >>> + errno: ETIMEDOUT >>> + >>> +Failed due to connection timeout >>> + >>> +BR/EDR connection refused >>> +========================= >>> + code: 0x000E >>> + errno: ECONNREFUSED >>> + >>> +Refused by the remote device due to limited resource, security reason or >>> +unacceptable address type. >>> + >>> +BR/EDR connection aborted by remote >>> +=================================== >>> + code: 0x000F >>> + errno: ECONNRESET >>> + >>> +Terminated by the remote device due to limited resource or power off. >>> + >>> +BR/EDR connection aborted by local >>> +================================== >>> + code: 0x0010 >>> + errno: ECONNABORTED >>> + >>> +Aborted by the local host. >>> + >>> +BR/EDR connection protocol error >>> +================================ >>> + code: 0x0011 >>> + errno: EPROTO >>> + >>> +Failed due to LMP protocol error. >>> + >>> +BR/EDR connection canceled >>> +========================== >>> + code: 0x0012 >>> + errno: none >>> + >>> +Failed due to cancellation caused by adapter drop, unexpected device drop, or >>> +incoming disconnection request before connection request is completed. >>> + >>> +BR/EDR connection unknown error >>> +=============================== >>> + code: 0x0013 >>> + errno: ENOSYS >>> + >>> +Failed due to unknown reason. >>> + >>> +LE connection invalid arguments >>> +=============================== >>> + code: 0x0101 >>> + errno: EINVAL >>> + >>> +Failed due to invalid arguments. >>> + >>> +LE connection not powered >>> +========================= >>> + code: 0x0102 >>> + errno: EHOSTUNREACH >>> + >>> +Failed due to adapter not powered. >>> + >>> +LE connection not supported >>> +=========================== >>> + code: 0x0103 >>> + errno: EOPNOTSUPP, EPROTONOSUPPORT >>> + >>> +Failed due to unsupported state transition of L2CAP channel or other features >>> +(e.g. LE features) either by the local host or the remote. >>> + >>> +LE connection already connected >>> +=============================== >>> + code: 0x0104 >>> + errno: EALREADY, EISCONN >>> + >>> +Either the BT IO is already connected or LE link connection in place. >>> + >>> +LE connection bad socket >>> +======================== >>> + code: 0x0105 >>> + errno: EBADFD >>> + >>> +Failed due to the socket is in bad state. >>> + >>> +LE connection memory allocation >>> +=============================== >>> + code: 0x0106 >>> + errno: ENOMEM >>> + >>> +Failed to allocate memory in either host stack or controller. >>> + >>> +LE connection busy >>> +================== >>> + code: 0x0107 >>> + errno: EBUSY >>> + >>> +Failed due to other ongoing operations, such as pairing, connecting, busy >>> +L2CAP channel or the operation disallowed by the controller. >>> + >>> +LE connection refused >>> +===================== >>> + code: 0x0108 >>> + errno: ECONNREFUSED >>> + >>> +Failed due to that LE is not enabled or the attempt is refused by the remote >>> +device due to limited resource, security reason or unacceptable address type. >>> + >>> +LE connection create socket >>> +=========================== >>> + code: 0x0109 >>> + errno: EIO >>> + >>> +Failed to create or connect to BT IO socket. This can also indicate hardware >>> +failure in the controller. >>> + >>> +LE connection timeout >>> +===================== >>> + code: 0x010A >>> + errno: ETIMEDOUT >>> + >>> +Failed due to connection timeout >>> + >>> +LE connection concurrent connection limit >>> +========================================= >>> + code: 0x010B >>> + errno: EMLINK >>> + >>> +Failed due to reaching the synchronous connection limit to a device. >>> + >>> +LE connection abort by remote >>> +============================= >>> + code: 0x010C >>> + errno: ECONNRESET >>> + >>> +Aborted by the remote device due to limited resource or power off. >>> + >>> +LE connection abort by local >>> +============================ >>> + code: 0x010D >>> + errno: ECONNABORTED >>> + >>> +Aborted by the local host. >>> + >>> +LE connection link layer protocol error >>> +======================================= >>> + code: 0x010E >>> + errno: EPROTO >>> + >>> +Failed due to link layer protocol error. >>> + >>> +LE connection GATT browsing >>> +=========================== >>> + code: 0x010F >>> + errno: none >>> + >>> +Failed to complete the GATT browsing. >>> + >>> +LE connection unknown error >>> +=========================== >>> + code: 0x0110 >>> + errno: ENOSYS >>> + >>> + Failed due to unknown reason. >>> diff --git a/src/error.c b/src/error.c >>> index 89517075e..73602c4bf 100644 >>> --- a/src/error.c >>> +++ b/src/error.c >>> @@ -27,6 +27,7 @@ >>> #include >>> #endif >>> >>> +#include >>> #include "gdbus/gdbus.h" >>> >>> #include "error.h" >>> @@ -43,6 +44,12 @@ DBusMessage *btd_error_invalid_args_str(DBusMessage *msg, const char *str) >>> "%s", str); >>> } >>> >>> +DBusMessage *btd_error_invalid_args_err(DBusMessage *msg, uint16_t err) >>> +{ >>> + return g_dbus_create_error(msg, ERROR_INTERFACE ".InvalidArguments", >>> + "0x%04X", err); >>> +} >>> + >>> DBusMessage *btd_error_busy(DBusMessage *msg) >>> { >>> return g_dbus_create_error(msg, ERROR_INTERFACE ".InProgress", >>> @@ -79,12 +86,24 @@ DBusMessage *btd_error_in_progress(DBusMessage *msg) >>> "In Progress"); >>> } >>> >>> +DBusMessage *btd_error_in_progress_err(DBusMessage *msg, uint16_t err) >>> +{ >>> + return g_dbus_create_error(msg, ERROR_INTERFACE ".InProgress", "0x%04X", >>> + err); >>> +} >>> + >>> DBusMessage *btd_error_not_available(DBusMessage *msg) >>> { >>> return g_dbus_create_error(msg, ERROR_INTERFACE ".NotAvailable", >>> "Operation currently not available"); >>> } >>> >>> +DBusMessage *btd_error_not_available_err(DBusMessage *msg, uint16_t err) >>> +{ >>> + return g_dbus_create_error(msg, ERROR_INTERFACE ".NotAvailable", >>> + "0x%04X", err); >>> +} >>> + >>> DBusMessage *btd_error_does_not_exist(DBusMessage *msg) >>> { >>> return g_dbus_create_error(msg, ERROR_INTERFACE ".DoesNotExist", >>> @@ -121,8 +140,100 @@ DBusMessage *btd_error_not_ready(DBusMessage *msg) >>> "Resource Not Ready"); >>> } >>> >>> +DBusMessage *btd_error_not_ready_err(DBusMessage *msg, uint16_t err) >>> +{ >>> + return g_dbus_create_error(msg, ERROR_INTERFACE ".NotReady", "0x%04X", >>> + err); >>> +} >>> + >>> DBusMessage *btd_error_failed(DBusMessage *msg, const char *str) >>> { >>> return g_dbus_create_error(msg, ERROR_INTERFACE >>> ".Failed", "%s", str); >>> } >>> + >>> +DBusMessage *btd_error_failed_err(DBusMessage *msg, uint16_t err) >>> +{ >>> + return g_dbus_create_error(msg, ERROR_INTERFACE ".Failed", "0x%04X", >>> + err); >>> +} >>> + >>> +uint16_t btd_error_bredr_conn_from_errno(int errno_code) >>> +{ >>> + switch (-errno_code) { >>> + case EALREADY: >>> + case EISCONN: // Fall through >> >> Don’t do this Fall through. It is actually not a fall through per se. This is just a statement with two case labels. That is perfectly normal and no compiler should complain. And frankly no C-programmer should be confused if this was intentional or not. > Corrected in v3. >> >>> + return BTD_ERR_BREDR_CONN_ALREADY_CONNECTED; >>> + case EHOSTDOWN: >>> + return BTD_ERR_BREDR_CONN_PAGE_TIMEOUT; >>> + case ENOPROTOOPT: >>> + return BTD_ERR_BREDR_CONN_PROFILE_UNAVAILABLE; >>> + case EIO: >>> + return BTD_ERR_BREDR_CONN_CREATE_SOCKET; >>> + case EINVAL: >>> + return BTD_ERR_BREDR_CONN_INVALID_ARGUMENTS; >>> + case EHOSTUNREACH: >>> + return BTD_ERR_BREDR_CONN_ADAPTER_NOT_POWERED; >>> + case EOPNOTSUPP: >>> + case EPROTONOSUPPORT: // Fall through >>> + return BTD_ERR_BREDR_CONN_NOT_SUPPORTED; >>> + case EBADFD: >>> + return BTD_ERR_BREDR_CONN_BAD_SOCKET; >>> + case ENOMEM: >>> + return BTD_ERR_BREDR_CONN_MEMORY_ALLOC; >>> + case EBUSY: >>> + return BTD_ERR_BREDR_CONN_BUSY; >>> + case EMLINK: >>> + return BTD_ERR_BREDR_CONN_CNCR_CONNECT_LIMIT; >>> + case ETIMEDOUT: >>> + return BTD_ERR_BREDR_CONN_TIMEOUT; >>> + case ECONNREFUSED: >>> + return BTD_ERR_BREDR_CONN_REFUSED; >>> + case ECONNRESET: >>> + return BTD_ERR_BREDR_CONN_ABORT_BY_REMOTE; >>> + case ECONNABORTED: >>> + return BTD_ERR_BREDR_CONN_ABORT_BY_LOCAL; >>> + case EPROTO: >>> + return BTD_ERR_BREDR_CONN_PROTO_ERROR; >>> + default: >>> + return BTD_ERR_BREDR_CONN_UNKNOWN; >>> + } >>> +} >>> + >>> +uint16_t btd_error_le_conn_from_errno(int errno_code) >>> +{ >>> + switch (-errno_code) { >>> + case EINVAL: >>> + return BTD_ERR_LE_CONN_INVALID_ARGUMENTS; >>> + case EHOSTUNREACH: >>> + return BTD_ERR_LE_CONN_ADAPTER_NOT_POWERED; >>> + case EOPNOTSUPP: >>> + case EPROTONOSUPPORT: // Fall through >>> + return BTD_ERR_LE_CONN_NOT_SUPPORTED; >>> + case EALREADY: >>> + case EISCONN: // Fall through >>> + return BTD_ERR_LE_CONN_ALREADY_CONNECTED; >>> + case EBADFD: >>> + return BTD_ERR_LE_CONN_BAD_SOCKET; >>> + case ENOMEM: >>> + return BTD_ERR_LE_CONN_MEMORY_ALLOC; >>> + case EBUSY: >>> + return BTD_ERR_LE_CONN_BUSY; >>> + case ECONNREFUSED: >>> + return BTD_ERR_LE_CONN_REFUSED; >>> + case EIO: >>> + return BTD_ERR_LE_CONN_CREATE_SOCKET; >>> + case ETIMEDOUT: >>> + return BTD_ERR_LE_CONN_TIMEOUT; >>> + case EMLINK: >>> + return BTD_ERR_LE_CONN_SYNC_CONNECT_LIMIT; >>> + case ECONNRESET: >>> + return BTD_ERR_LE_CONN_ABORT_BY_REMOTE; >>> + case ECONNABORTED: >>> + return BTD_ERR_LE_CONN_ABORT_BY_LOCAL; >>> + case EPROTO: >>> + return BTD_ERR_LE_CONN_PROTO_ERROR; >>> + default: >>> + return BTD_ERR_LE_CONN_UNKNOWN; >>> + } >>> +} >>> diff --git a/src/error.h b/src/error.h >>> index 7c8cad066..74d433aca 100644 >>> --- a/src/error.h >>> +++ b/src/error.h >>> @@ -24,22 +24,74 @@ >>> */ >>> >>> #include >>> +#include >>> >>> #define ERROR_INTERFACE "org.bluez.Error" >>> >>> +/* BR/EDR connection failure reasons >>> + * BT_ERR_* should be used as one of the parameters to btd_error_*_err(). >>> + */ >>> +#define BTD_ERR_BREDR_CONN_ALREADY_CONNECTED 0x0001 >>> +#define BTD_ERR_BREDR_CONN_PAGE_TIMEOUT 0x0002 >>> +#define BTD_ERR_BREDR_CONN_PROFILE_UNAVAILABLE 0x0003 >>> +#define BTD_ERR_BREDR_CONN_SDP_SEARCH 0x0004 >>> +#define BTD_ERR_BREDR_CONN_CREATE_SOCKET 0x0005 >>> +#define BTD_ERR_BREDR_CONN_INVALID_ARGUMENTS 0x0006 >>> +#define BTD_ERR_BREDR_CONN_ADAPTER_NOT_POWERED 0x0007 >>> +#define BTD_ERR_BREDR_CONN_NOT_SUPPORTED 0x0008 >>> +#define BTD_ERR_BREDR_CONN_BAD_SOCKET 0x0009 >>> +#define BTD_ERR_BREDR_CONN_MEMORY_ALLOC 0x000A >>> +#define BTD_ERR_BREDR_CONN_BUSY 0x000B >>> +#define BTD_ERR_BREDR_CONN_CNCR_CONNECT_LIMIT 0x000C >>> +#define BTD_ERR_BREDR_CONN_TIMEOUT 0x000D >>> +#define BTD_ERR_BREDR_CONN_REFUSED 0x000E >>> +#define BTD_ERR_BREDR_CONN_ABORT_BY_REMOTE 0x000F >>> +#define BTD_ERR_BREDR_CONN_ABORT_BY_LOCAL 0x0010 >>> +#define BTD_ERR_BREDR_CONN_PROTO_ERROR 0x0011 >>> +#define BTD_ERR_BREDR_CONN_CANCELED 0x0012 >>> +#define BTD_ERR_BREDR_CONN_UNKNOWN 0x0013 >>> + >>> +/* LE connection failure reasons >>> + * BT_ERR_* should be used as one of the parameters to btd_error_*_err(). >>> + */ >>> +#define BTD_ERR_LE_CONN_INVALID_ARGUMENTS 0x0101 >>> +#define BTD_ERR_LE_CONN_ADAPTER_NOT_POWERED 0x0102 >>> +#define BTD_ERR_LE_CONN_NOT_SUPPORTED 0x0103 >>> +#define BTD_ERR_LE_CONN_ALREADY_CONNECTED 0x0104 >>> +#define BTD_ERR_LE_CONN_BAD_SOCKET 0x0105 >>> +#define BTD_ERR_LE_CONN_MEMORY_ALLOC 0x0106 >>> +#define BTD_ERR_LE_CONN_BUSY 0x0107 >>> +#define BTD_ERR_LE_CONN_REFUSED 0x0108 >>> +#define BTD_ERR_LE_CONN_CREATE_SOCKET 0x0109 >>> +#define BTD_ERR_LE_CONN_TIMEOUT 0x010A >>> +#define BTD_ERR_LE_CONN_SYNC_CONNECT_LIMIT 0x010B >>> +#define BTD_ERR_LE_CONN_ABORT_BY_REMOTE 0x010C >>> +#define BTD_ERR_LE_CONN_ABORT_BY_LOCAL 0x010D >>> +#define BTD_ERR_LE_CONN_PROTO_ERROR 0x010E >>> +#define BTD_ERR_LE_CONN_GATT_BROWSE 0x010F >>> +#define BTD_ERR_LE_CONN_UNKNOWN 0x0110 >>> + >> >> What is the intention to split BR/EDR and LE here. You do know up-front what connection type you are. Trying to figure out from the error code what connection you have been trying to establish is plain wrong. > In fact the up-front connection type is not necessarily known. In the > case of dual-mode devices, such as Bose QC35, a D-Bus client can issue > Connect(), and it depends on the timing of connection request (adv > usually arrive first compared to inquiry result), it can be either > BR/EDR or LE link being established. Another aspect of this is the > metrics collection, where knowing transport can be handy. For > instance, we can associate the certain error to particular use cases > at application layer, and that can help targeting the bottleneck to > tackle. Then we need to find a different way to convey the transport chosen. Doing this by error message is a bad idea. >> >> The description is that you want to know exactly where the connection failed. And I think that can be established independent from the transport. > Indeed the intention is to know where it failed exactly. However, as > mentioned above, transport information is also an important piece of > information to know. We need to find a different way to inform about which transport failed (or better which was chosen in the first place). >> >> In addition, I don’t like the 0x00?? vs 0x01?? reservation of any number. That always goes bad at some point in the future. > As replied above, having a code attached instead of a string > description makes it easier for a D-Bus client to interpret and map to > corresponding handlers, but I am happy to explore other options as > well. You are creating namespaces within a 16-bit integer. That is never a good idea. It always goes wrong at some point in the future and then we are stuck with an API. Regards Marcel