Re: [RFC bluetooth-next 20/20] 6lowpan: bluetooth: add new implementation

Hi,

On 07/19/2016 10:49 AM, Luiz Augusto von Dentz wrote:

Hi Alex,

On Tue, Jul 19, 2016 at 12:52 AM, Alexander Aring [off-list ref] wrote:

quoted

quoted

quoted

If you have the current debugfs UAPI 1:1 already in some kind of stable
bluetooth API then I would give you the BIG advice to fix that and let
me look into that. (As far I know there exists idea's only, no
implementations).

There is the patches posted by Patrik implementing the management interface:

http://www.spinics.net/lists/linux-bluetooth/msg66486.html

Okay, just to be sure here, in the above document:

Controller ID = hdev(usually var name, struct hci_dev)->id

Interface Index = dev(usualy var name, struct net_device)->idx

Is this right? I think so, so my next stuff will base on that.

Yep.

quoted

quoted

Note that these commands are per interface index, so you would be able
to have two dongle talking to each other, we could in fact even
automate this to test with 2 virtual controllers.

We have similar automating testing in 802.15.4 6LoWPAN with virtual
transceiver drivers.

I always looked somehow for some virtual driver in bluetooth, does this
exist mainline?

Take a look at the emulator directory:

https://git.kernel.org/cgit/bluetooth/bluez.git/tree/emulator

cool.

quoted

quoted

It is about priorities, we should concentrate in making it work for
simpler cases, besides the RFC don't talk about subnets either.

I don't talking about subnets.

I am talking about "make the connect command per interface". Patrik
works shows the following:

Add Network Command
===================

        Command Code:           0x0043
        Controller Index:       <controller id>
        Command Parameters:     Address (6 Octets)
                                Address_Type (1 Octet)
        Return Parameters:      Address (6 Octets)
                                Address_Type (1 Octet)
                                Interface Index (4 Octets)

        This command is used to connect to establish a network connection
        to a remote BTLE node. A pre-requisite is that LE is supported
        by the controller, otherwise this command will return a
        "not supported" response.

        Possible values for the Address_Type parameter:
                0       Reserved
                1       LE Public
                2       LE Random

        This command generates a Command Complete event on success
        or failure.

        Possible errors:        Busy
                                Refused
                                Invalid Parameters
                                Not Supported
                                Invalid Index
                                Already Connected

So far I understand, this is "make the connect command per device", the
device in this case is not a "struct net_device" it's "struct hci_dev".

In the "possible" future case to having multiple interfaces you cannot
say on which interface this connect should be done. With "connect" I
mean the l2cap_chan_connect call.

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.

I am sure that there will be some use-case with namespaces some day.

In general:

In my opinion, having hci_dev as input parameter and as output the
interface will do something hidden behind which you can't control.
The Output return value "interface" will indicate on which interface
the operation was operated on. For me it's something behind which you
cannot control as user. E.g. When having multiple interfaces. On 1:1
mapping, I agree this should work.

But why not simple drop the interface idx from the Output and move it to
Input?

         Command Code:           0x0043
         Controller Index:       <controller id>
         Command Parameters:     Address (6 Octets)
                                 Address_Type (1 Octet)
                                 Interface Index (4 Octets)
         Return Parameters:      Address (6 Octets)
                                 Address_Type (1 Octet)

If we get some way that the 6LoWPAN interface can be created before and
not when doing the first "connect command" then the "Controller Index"
would be unnecessary because you would give that information when
creating an interface.

quoted

btw:
Also I don't know what's now the parameters "Address/Address_Type"
source/destination? Is the Input of them equal to the output?

That is always the destination address, and we needs its type to know
if it is public or private to act accordingly.

okay.

- Alex