Received: by 10.223.176.46 with SMTP id f43csp2875918wra; Mon, 22 Jan 2018 05:01:37 -0800 (PST) X-Google-Smtp-Source: AH8x226SObXmncgRuhqSRTeUhPdaZYAYoMIihsgdxAl2vmnWdkYKL9g+RnA5fin8LX/iTp6BvcCq X-Received: by 10.101.78.12 with SMTP id r12mr7255872pgt.33.1516626097471; Mon, 22 Jan 2018 05:01:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516626097; cv=none; d=google.com; s=arc-20160816; b=fhTruIRBX94O9vmiTaBcpSb2LlKK5rz12chvKFdnHDwlITMAGmY344smfqcgTVo3kQ pOkfs4NE46HJpzlDy4S9Yxf11/ySiV/SRo96KBa+d8VHTMWmfZbEcDEgVp46mCtkTmMh vOEKwDnFBhGCpDAncFaIDyKBzU0zkD0NtnjHRPV27a/5B1YDTMwG7oqiA0mmEb16Nhtw QvLunk7zJfLbom/uzMqQR+3jEuu3yYWHNwe9U8rj/HnjoinSr4YDBIyL8P38wkj1EZJq ++Jn6cTUF8BvhBTUD1q2Clp6ImL/73HaforCTgNZfA3xXgGXJFM9TIEEt5Nq53lx3B4u UQIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=XinQ2FpurfJrUTwID12ipUo47ZbJ9xMeUwqoQ6VA3uI=; b=MvrZjUyFfwpcFyAD3pwIhiM05k2QmF+1ip1xBBkNFPeYjSOL00bAv8QgYnGy5MyFGY NyYp/NiCtwDS8iFfH/ZgPgMZnoP+4CTev7x/nUPGFYaf5J5FiXqRdYvQr5tliMjZ8QKj TBQS1MsEL+JriUNi4Y9XJlcWVwU+xo3ZD+A+XSdyZWu79M9Q8u/WcpSIowEGgtbPfIvu H9irdAjgQMhBNWb9Rxh4PCEEOKx1jacg88tFK7w8ZP9OfTZhFzWgaz8PTkQJYvENELfA ia4PRjRmn4rBpiwKMLezrLk+GsfPPHhpi06Mh2vnZ93XBaJLv1KVMpdf7Y/VP+xTtidW 1oTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=bVD7ilwL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE 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 k9-v6si335000pll.578.2018.01.22.05.01.23; Mon, 22 Jan 2018 05:01:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=bVD7ilwL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751266AbeAVNAu (ORCPT + 99 others); Mon, 22 Jan 2018 08:00:50 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:34429 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751122AbeAVNAq (ORCPT ); Mon, 22 Jan 2018 08:00:46 -0500 Received: by mail-qt0-f193.google.com with SMTP id a27so7258215qtd.1; Mon, 22 Jan 2018 05:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XinQ2FpurfJrUTwID12ipUo47ZbJ9xMeUwqoQ6VA3uI=; b=bVD7ilwL7mGhcCaFPQ8b6BPx/+CHlz/wmaRCA4ZZ7wCXKBwuLHBYiA63UB8syVJFsn K5Gsyix+q4vhEx/tjOIRctYAyPd1kBxlgUi4ke4t7WqXFUpXtlKQK/ATmONFiEYsa0y7 s0q1+tQ40xGluMuDHeik2myj/ZlSmbYQg3w7i7C+nbp7TZxUP4Eo617XfLZEaAD36wsP 4tcR+siD1wbf5UKxgBR4140hO2oFr9P1cuHsvdcLIG8y6gaVt2FYixBgdw4yn/AE1sM4 Mt5raG6y2Zfk9qdH1oGIeGk1KGyx2FvKIN3FoF+xXOPj+yMbxHEOFF+pCyLnY00m9VvW wBUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XinQ2FpurfJrUTwID12ipUo47ZbJ9xMeUwqoQ6VA3uI=; b=jJM7TGaWwb7Mv7rVTI4idgKUxRMjCZC9JkHp10EzfDTPU/KKShb8qxRRIoplZeappi FsLIsafMmUls11UGajSSWHPHVBeNw7tTRn8xz/xgDp8313gz9YDBFYHhcVPfz4qd/qer FtZEnnmhvTq6vm6ycMwK03UEXKeisRk0hM6e8f6q0co/qlnff98C0OuMNzYCfnRS5d1U Z3QbNpThmPHdT4TT/skhmnr6XQ5DGaPR5qEPGyK0uaFr2ICVy831+NoGIJKMQE+FOUiP 6JdhthTQVLI0oxYhNIzVNCQVZLj/jwzxHnP31GOb2WuC2xXDoREtfa4pUITpqxmUkvzE /JCA== X-Gm-Message-State: AKwxytdwPyf/uOFzuHNwCn4kvHy9b9iRdvmGgknuZwECcI1kZYhP3h+P MaF82dXEUaxI24Hu+UkUtpwRKcHEuyyAH9ujWh3kBQ== X-Received: by 10.237.63.50 with SMTP id p47mr10278168qtf.104.1516626044331; Mon, 22 Jan 2018 05:00:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.17.13 with HTTP; Mon, 22 Jan 2018 05:00:43 -0800 (PST) In-Reply-To: References: <1516160848-471-1-git-send-email-yi2010.guo@samsung.com> From: Luiz Augusto von Dentz Date: Mon, 22 Jan 2018 11:00:43 -0200 Message-ID: Subject: Re: [PATCH] Bluetooth: 6lowpan: Fix disconnect bug in 6lowpan To: Alexander Aring Cc: Guo Yi , "linux-bluetooth@vger.kernel.org" , "open list:NETWORKING [GENERAL]" , Linux Kernel Mailing List , Marcel Holtmann , "Gustavo F. Padovan" , Johan Hedberg , David Miller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alex, On Wed, Jan 17, 2018 at 3:37 PM, Alexander Aring wrote: > Hi, > > 2018-01-17 7:15 GMT-05:00 Luiz Augusto von Dentz : >> Hi, >> >> On Wed, Jan 17, 2018 at 1:47 AM, Guo Yi wrote: >>> This patch fix the bluetooth 6lowpan disconnect fail bug. >>> >>> The type of the same address type have different define value in HCI layer >>> and L2CAP layer.That makes disconnect fail due to wrong network type.User >>> will not be able to disconnect from console with the network type that used >>> in connect. >>> >>> This patch add a var lookup_type, and covert the channel address type to >>> HCI address type. By these means, user can disconnect successfuly. >>> >>> Signed-off-by: Guo Yi >> >> While this fix seems alright the debugfs interface was never meant for >> production, in fact we are working on a replacement: >> > > Is the new API fixing the issue that the 6LoWPAN device creation is > done by iproute e.g.: > > ip link add link wpan0 name lowpan0 type lowpan > > or is there a special bluetooth API call needed, like the current case > with debugfs. > I know hcis are not netdevs, but it bothers me that we running into > two different worlds on how to deal with that and it just requires > "more" special bluetooth specific handling in user space applications. > Later more "netdev" capable link layers will maybe support 6LoWPAN and > then bluetooth might the only subsystem where different handling is > needed to do such job like that. Keep in mind that the transport on Bluetooth happens to be in a different layer, so you are basically suggesting that the kernel maintain a L2CAP connection, similar to TCP, which has several security implications. > We maybe need to support a special handling in "ip link add" to map to > bluetooth instead moving that to people in user space? Afaik ip tool cannot support any tunnel interface since the kernel cleanup any socket opened when the tool exit. Btw, with the patches above bluetoothd would take care of adding/removing the links automatically so at least this step will not be necessary. Other ip commands should work though. > - Alex -- Luiz Augusto von Dentz