From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D91BAC43387 for ; Thu, 10 Jan 2019 18:12:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8FFAF20675 for ; Thu, 10 Jan 2019 18:12:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rBjUIVEI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731007AbfAJSMx (ORCPT ); Thu, 10 Jan 2019 13:12:53 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:41624 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730008AbfAJSMw (ORCPT ); Thu, 10 Jan 2019 13:12:52 -0500 Received: by mail-wr1-f65.google.com with SMTP id x10so12432216wrs.8 for ; Thu, 10 Jan 2019 10:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nbUSS92dvtTGQvccTnxzMpOkaYqgXbE+qDQHxgAhuYU=; b=rBjUIVEI6LB8bJmBPk9wfr+25969AIZkQdLF/Bm2ywNAAtMiMscrXD32qzjGlUUbD5 +eyiXL9k26QcMeHQCE9xAibMwOU+bjI1U7LKjbn1rj3yNvLND+Hlg2d0B+9gR+c7gR41 x6FO/5sqiHYmquO2otmNU9jCMYwuU8Pj5sRZ/4qzqaXDiOLDcQUQ6VxA/cL8X3AMv989 kyWyJrhg4nCJ4TPaU4E0Tc4If3fCZKLe3bPtirW5L0ZCnHrdbAMpgEMlKmhsh/vlOREZ fIFeefvAha7/Hn/mMfJiWRhNNnKxrQSmqvw8EkFFiG+B0+ATU+7o3vqxyDZ5SF/vo63g KqrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nbUSS92dvtTGQvccTnxzMpOkaYqgXbE+qDQHxgAhuYU=; b=ruioeIMRuvv7RT3s6AdwaGrE+ks1CGV/NyhQmVSElJRJTzJDuM/V1weRfKKNv1BvXA P9BS/ysgTLyOKdouf+oIOU6wz/eEOFJvBWob+9i0Q94NKbzUTUW12j7RzfqTeSA/KBfM gZ1W5D0lopcP6M0VaGXwh7JL42Zm88kRYK88BRpULdIRyEg1UFRkZPpMgJq5P6u2jLjJ R7ZliLhrRPGO0z4/2hJGwCFUsQJQLCmAMCWLcbpQYbDeYxAU6uPyJ+Unr44SQswbuYXV FYyVOkk3jXTE7Zk6BmUQv8q5OwCYxp7yzB4W+fIG7W4vTGd3hhKADKzch/fl2Ut8qIFR Jesg== X-Gm-Message-State: AJcUukd6ndPOarfbO1RqLRTc6WikxbLPodgvFTm+yVXcZn1pduDkxs0u IiK+D5cwNNO3j1eF22peYonjB1AC X-Google-Smtp-Source: ALg8bN73eGvYgKX2ymQsCQrY4j3uD/ajte1l0ifRvb8qVklW3s2bLFJq9GshcKcx66eSlna+GLWSxw== X-Received: by 2002:adf:c108:: with SMTP id r8mr10720513wre.233.1547143968745; Thu, 10 Jan 2019 10:12:48 -0800 (PST) Received: from [192.168.2.164] (p5B08A983.dip0.t-ipconnect.de. [91.8.169.131]) by smtp.gmail.com with ESMTPSA id p6sm74167354wrx.50.2019.01.10.10.12.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jan 2019 10:12:48 -0800 (PST) Subject: Re: Multiple peers with bluetooth_6lowpan To: Luiz Augusto von Dentz Cc: "linux-bluetooth@vger.kernel.org" References: From: Josua Mayer Openpgp: preference=signencrypt Autocrypt: addr=josua.mayer97@gmail.com; prefer-encrypt=mutual; keydata= mQINBFtbYt4BEACysNSF+vmzzBvR+YgJDK6X34V+WUStfjN3YqbcClZxUWe2rOt3BfxsuG+a cmOHVmS5ufOOXE7dsB6w9eviNOO2h/XWCdyjnrtYY4bCxmDzyHV3MZW3Z4OlJWOFffOa5HPe fog8Xn5wsLm+tKyMWJAqSjJrJSJmmgucT/QkHOsnUtPRPSDRsTiWBZQgtplgVYswdaGxE8sy XIJJfpQVX9G6rm+1Qyc8BEGcgvx9cHjzaK+NbFPo8UsZZ1YxuqPba3Kr7NlmLFp78oTBYtTY 2bTCtNd/mBKkDd1qhEm/TqX1DElXlnWwKOEDX9FxvWIjVtVP04kdXJspb8U404GLbH3H86+D XAjAkXI7QY/CRsmENvi0wzxjb8PduWYslqJA6yMeoJY9iB1aiK/1LetfozUBX1nKhXCzfOz3 dAaHhUel0dylxRndQP7lpahvZw9FLv9Ijc2gafh7hQ7PxJue1H0v5nrOkyfxr9/kZSLnKk16 /LD88Wlu3O2oDNOc0Mcw29VGxTkHMsi5qWsYXGX4fFrIpmuZ9L1yNdY2Z0HJEMFC3oP7imts X05sQzIdDwlDe9afW5bI1QzYHeve1EvC3hDTjl3uAbKY5tOFs0S6bZo1mXDe7Ul6gCkMJSg3 j1WKRC9N1fp7sW9qVxfyFYljGVeN2UpJqBXEIghLewgetxnzSwARAQABtCVKb3N1YSBNYXll ciA8am9zdWEubWF5ZXI5N0BnbWFpbC5jb20+iQJOBBMBCgA4FiEEBGzKTuBeYuHyxSgAY7Jb EByN8BkFAltbZT0CGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQY7JbEByN8Bn97w// WLLmSYDg2e/zlcD0cjtRDnHliDk6b/FVoqPLlY1taFAIzQzptowYLGhwaid4HpghmwmeM0t4 auadcOPj6Cge/fW+9uTpehP+E4Knp1CpWVNNPfNcad/7wL98rBTy+3huaPnwAIeXdVdc7Jfi 3nnvX8o1NFuivZ7SXaBKtZo1iSm2B4yn7TndjQKqJ/TzQdYp9Sb7CiG1JWT/hAH8Zax8lETx BVhgOPZpe9RH108NlVnVwDtIN55O7iSMAVwl3ON3khuTVFtYmVd7iOFkzUx4TCJ6YSZsWQzz NHawbBavHE1DsDdT1BrJsz42DJjuBJXNtEDd/KRzzOhsLDjoZpoIvgFgeNAIxvLozae1ajvT 1g3Twgb+ewDVsmB9m2IjleNJyIlNG0vTX3/SQPsS6I3sVo1Q30rC6IUGBiK2PKJDkFcPz2xK YrdR49t5zBk6olXiCdoYgjlCkA8yxVaFMLMnLxzyfiD5ngT9k74j6CZV/M+M8/7tTyOOk+Ni wCe0NCrYk+PED9pLBQ294Z15aA0x83X4a1lmZOh7agspQ3Xsc1KwA7MpHy/P3sAZJt6P77Ft YbRXErbzm+ZkWGdCzEYF8khgds+4mTJFWH58Jm1rm0ZsYeyK+VyES/D1E8yCQalWYSw7yQ4I ivQwrzjl7HBNmSPMqHRzKSvgoGixABxKiOS5Ag0EW1ti3gEQAMngBnhTg9c0119KxFq1pJCh nsCNYlNQXVembZHjxCU7ui0sTJsDotJ4RZfFnIyXuDf0xPpLwxtQsdaShx66MqUEwFoni+X4 a8j+q6osWF51vNS8VXT3D/gmAubuf0CrVPWmgeU9IvsBtUotfq6dpLkBGqFe9pXHnaUovRbc cdXjYBFwUrpxAwNqOJWgLQ9ePEaZ3viXvr0KwIt2YH1n3XWeVqqpGmXevsioVKbP4Jgq8GFE pp9VnraEiQ+U8hYGjKRFyCisDSVhQzN1J+XDSYlQ7a4AQZ+C7yO4RJe95JDhc3WN0nzvyEcr AFLGgCWOxfEBg++upA3BTmVxESRAGTf+zo6y9rCAgB6Tbj2VZxN82MPbs9C7znKvQR8V5cUC XEYlmxIGSuuvJ8hc6q46ygZlZEPD1wvCV+UiQicEv0Qi3f2q4vNQOWCxYcQLIO6eJB6lnUba mC9rWQqQiVHc572U7gmsUbRtL8Re8ZuFQZbYNu+kDkMm4gqDLnpM6SLBZRmjGAYkwGssycUB nPDRWaKTDhnLqqjlFo+GAXNxt/rG6o2UGqJYASJ96ib0d1l7RbPshDj0hYmkKG62P9C4yR5n jkXXnjJKbHcraT3w+WO+bq6qDGiRJGtlYr2u8Y687k/xJzgRRLDdIgO+UEgMNdc5NUzj1f+M SmUCySrkuVS7ABEBAAGJAjYEGAEKACAWIQQEbMpO4F5i4fLFKABjslsQHI3wGQUCW1ti3gIb DAAKCRBjslsQHI3wGUU9EACqTPgZ8zuH0iBhdViM/RSjXoSUEre40ZdqfX4PwvYw2LWqPO2l hMEFB18ljpTQGg5sMBhuzIRWlB7X7E2Pe3cNG6wtzHaaDHr3DXxir/Y+hH3x7Xh8XduzKvsf nYxgd8BrNXCeDzzgGzjw27mieAHmitu+TNoq8+whceZ5FVtIs5+1lovHEduAYqMNg6acAjYw vCJcCqMD+LwZ7MuZNmzVsmTBOXYt89G51TzEJNnixhpLfvJQv6XjfB3GSQX5t2K7eCnHQjcW HwZCi9+/IznvuKIdXtoXDkEYO99/hXq8PYyPzwzQuuhxD7q2y4Vepg892Wd25VXoki1QNDxb BSOR0JYYYYi8uUaMUwb//aVOeDSrVB6MC79HezU0U6WabAbwmDMg5RYGwBtOLOg5V4khPGBD S4ntspMxn6uwHmUP3bQI9i4/R3ZCbm82BKrDnumvgXA2ZjOocm4KnBUq7iFcHCHtXTF0cP3f CKO5ue43dppoEyy/YbY+MykMGSDds0Zo1WS7BLtY1jU57BJpeA2LyB+tlnqneBY7bSiCnLFk R445GWURcesv2Be076yKhbVggsu2+1yv+NbToFBhLNhqHJH0e0nUrxmvoWDYRhGIODRtk3dk m/pY86DbEeNK+Y8ByMRDt5Pa0RFAOeDAxA8BcPD1/koQbNgp0it70I2nNrkCDQRbW2TiARAA yZ4qQ+6XWKDnK8f8fHUSc5U+C8yQJwwjwq8YjTOJAGlrJPH62ap1Bs8KKd0HXLYx3Z0aAOtw lGWYUEJtHQAMUed8sYz08dSs5XrRQ0p50o+7Jg12XAqaCqcQjq2XS9YImBB4W2GQASiHwDpR ZlJT+s4CfozWMiK0yBiYyYEXv3ndkXq2DlOYXIG3HxGH881RentUS4ufRpe3jS148pKjYg5O p142XP9jBVO9sSqMcpQnnJaRlLxt/f3WvhOAgSui+E/VTkR++Avo16hcrM+us05YuGePzHLB 81ZcENAts9VRBSH0yM1uA1omWgy+iVMqTTtz0KyI5huiktNkDvoT4eO0qV9bvaED+vrZR+2n 25TuqIPoQpAW6yfdgot/2MyRGEFlBvmshFDuUBwR2HIfIrewb+pCpif9YTCXbT9k4SOwYirJ TvItKv/w/AVOQ5jpBd7J2+fsirNYhdC2DgEPW8aJGra0ElwJBS/bS3eIuhQt3jtoTlK9FN7Z eE0hpFLqlsJZ3DYunsQ59alZjHo5u9qLDDI2f916zsbI+eajQva9ax/kXWXcEHpQk20MFj7c AT4tCbFYy84sPqKMEccY2BrbnlzKvSwHqRJAyK0TApKJk2EG/io6SMU7Ez6O0Rv2JW2XQy8Q ROGvD1IwYXOGdz42CeNHTAGvWUwb+xHTAYEAEQEAAYkEbAQYAQoAIBYhBARsyk7gXmLh8sUo AGOyWxAcjfAZBQJbW2TiAhsCAkAJEGOyWxAcjfAZwXQgBBkBCgAdFiEEp/mKrntZgfn46C9m OMa81b1flPwFAltbZOIACgkQOMa81b1flPyzIw//XY+Lf7v50TDbaks2bHc7sgysIQlYMLjE QD4tLXeowgl6NB8uYvU3mok/mgkClXEmYUqNYZtBZ9lW5wdOlZ9tjWKshZEXtCadROAq0ux7 J5nJMgtQRif9+QmW/DSOR02LZ1x7qGWBbMBGT8kYX4AiXo1RMORbcoXz/a6+RO8LXQeAYdrF QIbb5OzVKnAiVLirCUnI3ZMfgyjtAgcHYSNVggHbBOI5bJEwFQvMuD65wzbgLbNQBJXNMeZR R9WucRm9GcFZgX+XlwGx/Lls16iH+tgvEnoUJnukNad+EeGESBputyGhtS5tknF1CN7MxHj+ MI+GOpkcK1+2TUcA4CEn89KiLNVvIkLemWDcBwXC3okiFXGaqmIOGHw4ngErGPbKcmChO/3h lRAJYVuYLStJMPcgr+Q8b5li1EzezV2NW3MNpmXEpDnA3GFoch6krI0cyys8680ToByTwRHZ HpD4MJNPdS60ZL75gfnO+kTHFirlvw/7Omo+CfbCxTQC2uUneSMvzpZe4nf0/UdYXbo8t7AR diUZzKYsfzl/wKtzLaKWvuVJZnV5j+p67uBwoqtCzwZd7srOo1zTmlcHwjcNX0ks/P02Nxne 8fUYjDzvKm3XZSL7PHoxiQmZlcT13r3thL45SO7DTQCTgRlYPsmM45IZPdmAO03ff0uz2SaP HA+TYQ/5AeGp8YXeWJT0ts+7wz7Mf2ztTB/CSusQ44CiboBOKu0+ED5GzfLtk+eDZDXIIWhQ yxey8G9JRrthIdRuxeTKqSOePnIyBp8cNllgx7cgyL2oXCHVVOOk8mRC97GoFxw35Ls8FQzg knrC0xbFytCLJVIwOXYtJRc+kkqa4X8znhHtSicoUSriSab8vQR7EedXxOSt1abWVh8Y+inn hW8nr/lPGdcZlCff72tLlHZEgdwY1o6qKZkudiTdwTwpB+xYDv58TJKDtCUaFiKIjP6YVSwi OgbyzAW1diMI246jJg/x+RytRzkWkg4HvOJiUM3y2pr9KaHjFzMBSYADukTuJ6MkcvC1aqsY whKXMx5cWMpCisP6kZQNfsfM5UdvFghk+2bs33XNPFOilBozFo9OkEPpc8tezZqq7seZupYX 4AsCiHxwat8Z+I6ecNNIc0O8zkzUPqJotWehO12vlTpPU4qyDjyn16Ude1Nb+y6cK3R1Bu1+ baaDWy6Yx9bIat1koYXY0TD9hhIRdQ1Z3T0qBqm2b9oMT8XzhIhlBzwkrku5XmVfHILh6m/D Atc5XoeNksMaV6XsdxSAsBT6Vy5Ancd9LQ6hx2F4N/EY2K+X/j63RQwyJSrHXWHyY1if/TY3 CKEuEwlKLbUIs14huWIjQI1HmQ9RjWe3DUkI6Y6MpmY= Message-ID: <972f45b3-3afb-58ef-6a05-e84d09087775@gmail.com> Date: Thu, 10 Jan 2019 19:12:47 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Luiz, Am 10.01.19 um 19:01 schrieb Luiz Augusto von Dentz: > Hi Josua, > > On Thu, Jan 10, 2019 at 1:49 PM Josua Mayer wrote: >> >> Good day once more, >> >> I have now identified a chain of calls leading up to the described >> issue, along with a work-around: >> >> The first step was discovering fishy debug messages in dmesg: >> [ 235.505517] Connecting to first module while both are powered >> [ 237.394085] ifindex 5 peer bdaddr 00:b1:fc:8c:6e:47 type 1 my addr >> a4:d5:78:11:cf:6f type 1 >> [ 241.872089] dest IP fe80::b1:fcff:fe8c:6e47 >> [ 241.872104] peers 1 addr fe80::b1:fcff:fe8c:6e47 rt (null) >> [ 241.872124] xmit bt0 to 00:b1:fc:8c:6e:47 type 1 IP 6800::600 chan >> (ptrval) >> [ 242.356387] Connecting to second module >> [ 244.073592] dest IP fe80::b1:fcff:fe8c:6e47 >> [ 244.073603] peers 2 addr fe80::b1:fcff:fe8c:6e47 rt (null) >> [ 244.073607] no such peer >> >> We can see here how the first module is connected, and packets to its >> link-local address are being transmitted. >> Then the second module is connected and the number of peers updates to 2. >> Now we have another packet for the first modules link-local address. We >> know there are 2 peers, but for some reason we get a message saying "no >> such peer"! >> >> Luckily this message was easy to trace: >> See net/bluetooth/6lowpan.c:setup_header >> This message is a direct result of a previous call to peer_lookup_dst >> returning null. >> Now while reviewing peer_lookup_dst, keep in mind that we are looking >> for a difference in behaviour when there is one, and when tehre are at >> least two peers. >> Let me just quote here: >> if (count == 1) { >> peer = list_first_or_null_rcu(&dev->peers, struct lowpan_peer, list); >> return peer; >> } >> >> If there is only one peer, no checks are performed at all, it is simply >> assumed that this peer mist be the one to receive packets for the given >> address. >> So this is the one peers, or one module connected case - which works >> just fine. >> >> Then follows a curious case that I do not fully understand: >> if no route is known, and no gateway was specified in packet data, do >> not even search for the right peer, simply return 0: >> if (!rt) { >> nexthop = &lowpan_cb(skb)->gw; >> >> if (ipv6_addr_any(nexthop)) >> return NULL; >> } >> ^^ I believe this decision is wrong. >> There might be neither route nor gateway, if the destination is a peer. >> >> I have come up with the following work-around: >> - nexthop = &lowpan_cb(skb)->gw; >> - >> - if (ipv6_addr_any(nexthop)) >> - return NULL; >> + if (ipv6_addr_any(&lowpan_cb(skb)->gw)) { >> + /* There is neither route nor gateway, >> + * probably the destination is a direct peer. >> + */ >> + nexthop = daddr; >> + } else { >> + /* There is a known gateway >> + */ >> + nexthop = &lowpan_cb(skb)->gw; >> + } >> I am submitting this patch as separately as: >> [RFC] bluetooth_6lowpan: search for destination address in all peers >> It is by no means finished and meant to illustrate the core issue, and >> allow for a discussion around the control logic, and purpose of >> Please comment if I have understood the purpose of the peer_lookup_dst >> function. >> I might even suggest removing the special handling of one peer ... . > > I like this version better but apparently the patch you have sent is > only matching part of the address, not sure why you had refactored > that. If I recall the reason why peer_lookup_dst exists is that we > need to resolve the channel where to send the packets. Actually I didn't reafactor. The two patches actually handle 2 different issues. The first one deals with what I described in this topic; The second patch is very hackish and meant to illustrate the next step where we want to talk to dynamically assigned addresses. I believe the cache of known neighbours should be checked for the mac address, which in turn could be the search criteria for peers. ip -6 neighb 2004::39:d3ff:fe29:921c dev bt0 lladdr 00:39:d3:29:92:1c REACHABLE 2004::b1:fcff:fe8c:6e47 dev bt0 lladdr 00:b1:fc:8c:6e:47 REACHABLE > >> Yours sincerely >> Josua Mayer >> >> >> Am 08.01.19 um 19:57 schrieb Josua Mayer: >>> Greetings everybody, >>> >>> I want to present to you an issue I am having the 6LoWPAN over BLE >>> facility in the kernel. >>> I have reached the point where I don't know where, what and how to debug >>> the situation and am hoping for some advice here: >>> >>> First an overview of the setup: >>> 1. an SBC with BLE capable Bluetooth chip >>> 2. multiple Nordic nRF52840 modules >>> >>> This is the problem I have observed: >>> 1. One Nordic module is powered - SBC connects to it >>> --> ping6 works flawlessly till the module restarts >>> --> communication with the remote server works as expected >>> >>> 2. Two Nordic modules are powered - SBC connects only to one at a time >>> --> ping6 works flawlessly till the module restarts >>> --> communication with the remote server works as expected >>> >>> 3. Two Nordic modules are powered - SBC connects to both >>> --> ping6 receives no more replies as soon as the second module is connected >>> --> communication to the remote server stops as soon as the second >>> module is connected >>> >>> Test Case: >>> rfkill unblock 0 >>> modprobe bluetooth_6lowpan >>> echo -n 'module bluetooth_6lowpan +p' > >>> /sys/kernel/debug/dynamic_debug/control >>> >>> while true; do ping6 -c 1 -I bt0 fe80::b1:fcff:fe8c:6e47 || true; sleep >>> 1; done >>> >>> echo "Connecting to first module while both are powered" > /dev/kmsg >>> echo "connect 00:B1:FC:8C:6E:47 1" > >>> /sys/kernel/debug/bluetooth/6lowpan_control >>> # sit back and watch pings till module restarts >>> echo "Connecting to first module while both are powered" > /dev/kmsg >>> echo "connect 00:B1:FC:8C:6E:47 1" > >>> /sys/kernel/debug/bluetooth/6lowpan_control >>> # wait till first ping goes through >>> echo "Connecting to second module" > /dev/kmsg >>> echo "connect 00:39:D3:29:92:1C 1" > >>> /sys/kernel/debug/bluetooth/6lowpan_control >>> # Expected: ping6 continues to receive replies >>> # Actual result: ping6 times out >>> >>> Please see attached dmesg.log from this test case, with dynamic >>> debugging enabled for module bluetooth_6lowpan. >>> >>> The Nordic modules are programmed to advertise themselves for >>> establishing a connection; Then they start communication with a server >>> on the internet over ipv6. Finally they are rebooted by a watchdog. >>> While a module is connected, it can be pinged by its link-local address >>> which is derived from its MAC address and thereby known. >>> >>> As you may have noticed I just wrote "SBC" above. >>> That is because I have done this experiment with 3 different SBCs: >>> 1. SolidRun HummingBoard with i.MX6 uSOM Revision 1.5 >>> features Ti WL18MODGB combined WiFi and Bluetooth module >>> - linux-image-4.20.0-trunk-armmp_4.20-1~exp2_armhf.deb >>> (+BT_HCIUART=m, +BT_HCIUART_LL=y, +DYNAMIC_DEBUG=y) >>> ^^ This system was used to produce the attached dmesg.log >>> >>> 2. RaspberryPi 3B >>> 3. RaspberryPi 3B+ >>> - rpi-4.15.y (from their github) >>> - rpi-4.16.y (from their github) >>> - rpi-4.17.y (from their github) >>> - rpi-4.18.y (from their github) >>> - rpi-4.19.y (from their github) >>> - rpi-4.20.y (from their github) >>> bcm2709_defconfig >>> zImage modules dtbs -j12 >>> gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf >>> >>> rpi-4.14.y suffers from a busy kworker (Workqueue: hci0 hci_rx_work >>> [bluetooth]) making tests difficult. >>> >>> Supposedly back in 4.4.8-v7 on raspberrypi this issue with multiple >>> peers did not exist, while the busy kworker did pop up after time >>> requring a reboot. >>> I did not verify or test with that rather old version yet. >>> Would it be a good idea to start from that 4.4.8 rpi fork working up to >>> 4.15 to find the place where it broke? I feel like this kind of work is >>> difficult >>> when forks are involved. >>> >>> Are there any components of the kernel in particular that could be verified >>> in order to figure out what is going wrong? >>> >>> >>> Yours sincerely >>> Josua Mayer >>> > > >