Hi Luiz,
>>> To make the commands more generic, IPSP has been renamed Network. In order
>>> to be more generic, a network role has been added to the commands rather
>>> than have a specific command for role setting. With this more networking
>>> than just 6LowPAN can be handled in the future; whether 1 octet is enough
>>> to handle possible future roles OR'ed together remains to be seen and
>>> comments on the subject are appreciated.
>>>
>>> Handling incoming connection authorization is another topic to discuss
>>> with an initial proposal already on the mailing list. I'd be glad to update
>>> this RFC with the outcome of that discussion.
>>>
>>>
>>> Patrik
>>>
>>> doc/doc.txt | 0
>>> doc/mgmt-api.txt | 172 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 172 insertions(+)
>>> create mode 100644 doc/doc.txt
>>>
>>> diff --git a/doc/doc.txt b/doc/doc.txt
>>> new file mode 100644
>>> index 0000000..e69de29
>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>> index 731a088..060b751 100644
>>> --- a/doc/mgmt-api.txt
>>> +++ b/doc/mgmt-api.txt
>>> @@ -2801,6 +2801,127 @@ Start Limited Discovery Command
>>> Invalid Index
>>>
>>>
>>> +Get Networks Command
>>> +====================
>>> +
>>> + Command Code: 0x0042
>>> + Controller Index: <controller id>
>>> + Command Parameters:
>>> + Return Parameters: Interface Index (4 Octets)
>>> + Connection_Count (2 Octets)
>>> + Address1 {
>>> + Address (6 Octets)
>>> + Address_Type (1 Octet)
>>> + Network_Role (1 Octet)
>>> + }
>>> + Address2 { }
>>> + ...
>>> +
>>
>> so if we want to extend this to BNEP eventually, then the interface index needs to be per Network block (and it is Network1 and not Address1).
>>
>> I know that this means for multiple IPSP networks, the interface index would repeat since there is really only one, but I think that is something the application can easily figure out.
>
> Actually with this concept it looks a lot like a bridge so I wonder if
> we really want to duplicate this functionality, the bridge actually
> already takes care of routing even though it seems unlikely that we
> will have multiple peer connected I suppose the router device can end
> up in a star topology, anyway with the current module it actually set
> the peer to peer flag which perhaps is not what we want in case of
> router.
you can not talk about bridges in the context of IPSP. They operate on different levels. BNEP is Ethernet and IPSP is pure IPv6.
>>> + This command is used to retrieve a list of BTLE network
>>> + connections. A pre-requisite is that LE is already
>>> + enabled, otherwise this command will return a "rejected"
>>> + response.
>>> +
>>> + Possible values for the Address_Type parameter:
>>> + 0 Reserved
>>> + 1 LE Public
>>> + 2 LE Random
>>> +
>>> + Possible values for the Network_Role parameter:
>>> + 0 Reserved
>>> + 1 6LoWPAN Node
>>> + 2 6LoWPAN Router
>>
>> I wonder if here we actually want to call it IPSP Node instead. I only dislike IPSP in the command name. In parameters it seems fine.
>>
>> And do we need to differentiate between Node and Router here. I think that at some point Johan and discussed that the application (aka bluetoothd) is responsible for adding advertising instances. I wonder if we consider this more like Add Device were we punch a whole for allowing incoming connections. Keep in mind there is an extra thread ongoing about adding Add Device Type == 0x03 for exactly that case.
>
> In that case why not make Type 0x03 as "Trust this device", this would
> make a lot of things simpler including not sending L2CAP responses
> with authorization pending when the device is trusted saving some time
> in the process.
Add Device Type == 0x03 is for allowing incoming connections and allowing us to use whitelist for efficient processing on the link layer. I have no idea what L2CAP has to do with that here.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
