Return-Path: From: Michael Richardson To: Luiz Augusto von Dentz cc: Alexander Aring , linux-wpan@vger.kernel.org, kernel@pengutronix.de, kaspar@schleiser.de, Jukka Rissanen , "linux-bluetooth@vger.kernel.org" , Patrik Flykt Subject: Re: [RFC bluetooth-next 20/20] 6lowpan: bluetooth: add new implementation In-Reply-To: References: <20160711195044.25343-1-aar@pengutronix.de> <20160711195044.25343-21-aar@pengutronix.de> <11469f72-fa15-5545-387c-ecd051b74897@pengutronix.de> <190983bc-9467-8ff8-436c-ca1fcdfe001b@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Jul 2016 10:48:24 -0400 Message-ID: <20912.1468939704@obiwan.sandelman.ca> Sender: linux-wpan-owner@vger.kernel.org List-ID: Luiz Augusto von Dentz wrote: > And why would we want more than one one net_dev per hci_dev, the > rfc7668 only talks about star topology: > https://tools.ietf.org/html/rfc7668#section-2.2 > Bluetooth currently don't have support for a mesh topology, and anyway > I don't think the userspace would need to be involved in the selection > of the netdev since this is beyond the Bluetooth interface. In PAN for > example we end up doing one netdev per connection and the which the > userspace managing using a bridge. BTLE 4.2 moves quite far to supporting a mesh, but doesn't yet get there. I'm told that it will come. BTLE 4.2 does support switching to which star one belongs quickly enough that one could actually route, but it's probably not practical yet. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [