---
v2 sorts the commands and parameters according to comments.
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 { }
+ ...
+
+ 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
+
+ For devices using resolvable random addresses with a known
+ identity resolving key, the Address and Address_Type will
+ contain the identity information.
+
+ This command can only be used when the controller is powered.
+
+ This command generates a Command Complete event on success or
+ a Command Status event on failure.
+
+ Possible errors: Invalid Parameters
+ Not Powered
+ Invalid Index
+
+
+Add Network Command
+===================
+
+ Command Code: 0x0043
+ Controller Index: <controller id>
+ Command Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Network_Role (1 Octet)
+ Return Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Network_Role (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 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
+
+ This command generates a Command Complete event on success
+ or failure.
+
+ Possible errors: Busy
+ Refused
+ Invalid Parameters
+ Not Powered
+ Invalid Index
+ Already Connected
+
+
+Remove Network Command
+======================
+
+ Command Code: 0x0044
+ Controller Index: <controller id>
+ Command Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Network_Role (1 Octet)
+ Return Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Network_Role (1 Octet)
+
+ This command is used to disconnect a network connection from a
+ remote BTLE node. 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
+
+ This command generates a Command Complete event on success
+ or failure.
+
+ Possible errors: Busy
+ Not Connected
+ Invalid Parameters
+ Not Powered
+ Invalid Index
+
+
Command Complete Event
======================
@@ -3645,3 +3766,54 @@ Advertising Removed Event
The event will only be sent to management sockets other than the
one through which the command was sent.
+
+
+Network Added Event
+===================
+
+ Event Code: 0x0025
+ Controller Index: <controller id>
+ Event Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Network_Role (1 Octet)
+ Interface Index (4 Octets)
+
+ This event indicates that a network connection to a remote
+ BTLE node has been established successfully.
+
+ Possible values for the Address_Type parameter:
+ 1 LE Public
+ 2 LE Random
+
+ Possible values for the Network_Role parameter:
+ 1 6LoWPAN Node
+ 2 6LoWPAN Router
+
+ For devices using resolvable random addresses with a known
+ identity resolving key, the Address and Address_Type will
+ contain the identity information.
+
+
+Network Removed Event
+=====================
+
+ Event Code: 0x0026
+ Controller Index: <controller id>
+ Event Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Network_Role (1 Octet)
+
+ This event indicates that the BTLE network connection to a remote
+ node has been lost.
+
+ Possible values for the Address_Type parameter:
+ 1 LE Public
+ 2 LE Random
+
+ Possible values for the Network_Role parameter:
+ 1 6LoWPAN Node
+ 2 6LoWPAN Router
+
+ For devices using resolvable random addresses with a known
+ identity resolving key, the Address and Address_Type will
+ contain the identity information.
--
2.1.4
Hi,
On Tue, 2016-03-01 at 08:51 -0800, Marcel Holtmann wrote:
> Hi Patrik,
>
> > 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.
Let's do that.
> > + 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.
At first I thought a network role would come in handy, but it does not
actually produce any value here. It's simpler to just implement the
Add/Remove Network commands and rely on the application knowing what it
is doing. I'll remove the Network_Role.
If only whitelisted or non-blacklisted nodes are allowed to connect, no
further authorization signalling on new incoming connections is
necessary. Looks simple, except that Add Device with type 0x03
whitelisting needs also to be implemented by somebody, right?
> > +
> > + For devices using resolvable random addresses with a known
> > + identity resolving key, the Address and Address_Type will
> > + contain the identity information.
> > +
> > + This command can only be used when the controller is powered.
> > +
> > + This command generates a Command Complete event on success or
> > + a Command Status event on failure.
> > +
> > + Possible errors: Invalid Parameters
> > + Not Powered
> > + Invalid Index
> > +
> > +
> > +Add Network Command
> > +===================
> > +
> > + Command Code: 0x0043
> > + Controller Index: <controller id>
> > + Command Parameters: Address (6 Octets)
> > + Address_Type (1 Octet)
> > + Network_Role (1 Octet)
> > + Return Parameters: Address (6 Octets)
> > + Address_Type (1 Octet)
> > + Network_Role (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 already
> > + enabled, otherwise this command will return a "rejected"
> > + response.
>
> Do we really care if LE is enabled. I mean to some level it is
> implicit since you give an LE address. On the other hand, we could
> just let it program anything it wants. It just never gets executed if
> LE gets disabled.
>
> The reason I am saying this is that we do not define what happens to
> all these networks if you later on disable LE. We would have to send
> events to notify about changes.
>
> Refusing LE based entries for a BR/EDR only controller is fine, but if
> the controller is LE capable we might need to be careful.
Again it's easier for everybody if only the LE capability of the
controller is checked. I will remove the text about LE being enabled.
> > +
> > + 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
> > +
> > + This command generates a Command Complete event on success
> > + or failure.
> > +
> > + Possible errors: Busy
> > + Refused
> > + Invalid Parameters
> > + Not Powered
> > + Invalid Index
> > + Already Connected
> > +
> > +
> > +Remove Network Command
> > +======================
> > +
> > + Command Code: 0x0044
> > + Controller Index: <controller id>
> > + Command Parameters: Address (6 Octets)
> > + Address_Type (1 Octet)
> > + Network_Role (1 Octet)
> > + Return Parameters: Address (6 Octets)
> > + Address_Type (1 Octet)
> > + Network_Role (1 Octet)
> > +
> > + This command is used to disconnect a network connection from a
> > + remote BTLE node. 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
> > +
> > + This command generates a Command Complete event on success
> > + or failure.
> > +
> > + Possible errors: Busy
> > + Not Connected
> > + Invalid Parameters
> > + Not Powered
> > + Invalid Index
> > +
> > +
> > Command Complete Event
> > ======================
> >
> > @@ -3645,3 +3766,54 @@ Advertising Removed Event
> >
> > The event will only be sent to management sockets other than the
> > one through which the command was sent.
> > +
> > +
> > +Network Added Event
> > +===================
> > +
> > + Event Code: 0x0025
> > + Controller Index: <controller id>
> > + Event Parameters: Address (6 Octets)
> > + Address_Type (1 Octet)
> > + Network_Role (1 Octet)
> > + Interface Index (4 Octets)
> > +
> > + This event indicates that a network connection to a remote
> > + BTLE node has been established successfully.
> > +
> > + Possible values for the Address_Type parameter:
> > + 1 LE Public
> > + 2 LE Random
> > +
> > + Possible values for the Network_Role parameter:
> > + 1 6LoWPAN Node
> > + 2 6LoWPAN Router
> > +
> > + For devices using resolvable random addresses with a known
> > + identity resolving key, the Address and Address_Type will
> > + contain the identity information.
> > +
> > +
> > +Network Removed Event
> > +=====================
> > +
> > + Event Code: 0x0026
> > + Controller Index: <controller id>
> > + Event Parameters: Address (6 Octets)
> > + Address_Type (1 Octet)
> > + Network_Role (1 Octet)
> > +
> > + This event indicates that the BTLE network connection to a remote
> > + node has been lost.
> > +
> > + Possible values for the Address_Type parameter:
> > + 1 LE Public
> > + 2 LE Random
> > +
> > + Possible values for the Network_Role parameter:
> > + 1 6LoWPAN Node
> > + 2 6LoWPAN Router
> > +
> > + For devices using resolvable random addresses with a known
> > + identity resolving key, the Address and Address_Type will
> > + contain the identity information.
>
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
>
> I though you were suggesting using it instead of regular
> authorization, in that case we will need to authorize peers connecting
> in some other means which is might be necessary for the
> node/peripheral.
that is pretty much the question here. Does adding it means an implicit Add Device internally. Or does it mean that the application has to do it all by itself. Same argument can be made for Add Advertising.
Regards
Marcel
Hi Marcel,
On Wed, Mar 2, 2016 at 5:15 PM, Marcel Holtmann <[email protected]> wrote=
:
> Hi Luiz,
>
>>>> To make the commands more generic, IPSP has been renamed Network. In o=
rder
>>>> to be more generic, a network role has been added to the commands rath=
er
>>>> than have a specific command for role setting. With this more networki=
ng
>>>> than just 6LowPAN can be handled in the future; whether 1 octet is eno=
ugh
>>>> 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 u=
pdate
>>>> 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
>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> +
>>>> + 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 ind=
ex 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 di=
fferent 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 t=
hat at some point Johan and discussed that the application (aka bluetoothd)=
is responsible for adding advertising instances. I wonder if we consider t=
his more like Add Device were we punch a whole for allowing incoming connec=
tions. Keep in mind there is an extra thread ongoing about adding Add Devic=
e Type =3D=3D 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 =3D=3D 0x03 is for allowing incoming connections and allo=
wing us to use whitelist for efficient processing on the link layer. I have=
no idea what L2CAP has to do with that here.
I though you were suggesting using it instead of regular
authorization, in that case we will need to authorize peers connecting
in some other means which is might be necessary for the
node/peripheral.
--=20
Luiz Augusto von Dentz
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
Hi Marcel,
On Tue, Mar 1, 2016 at 6:51 PM, Marcel Holtmann <[email protected]> wrote=
:
> Hi Patrik,
>
>> To make the commands more generic, IPSP has been renamed Network. In ord=
er
>> 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 enoug=
h
>> 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 upd=
ate
>> 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
>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> +
>> + 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 wo=
uld repeat since there is really only one, but I think that is something th=
e 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.
>> + 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 di=
slike IPSP in the command name. In parameters it seems fine.
>
> And do we need to differentiate between Node and Router here. I think tha=
t at some point Johan and discussed that the application (aka bluetoothd) i=
s responsible for adding advertising instances. I wonder if we consider thi=
s more like Add Device were we punch a whole for allowing incoming connecti=
ons. Keep in mind there is an extra thread ongoing about adding Add Device =
Type =3D=3D 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.
>
>> +
>> + For devices using resolvable random addresses with a known
>> + identity resolving key, the Address and Address_Type will
>> + contain the identity information.
>> +
>> + This command can only be used when the controller is powered.
>> +
>> + This command generates a Command Complete event on success or
>> + a Command Status event on failure.
>> +
>> + Possible errors: Invalid Parameters
>> + Not Powered
>> + Invalid Index
>> +
>> +
>> +Add Network Command
>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> +
>> + Command Code: 0x0043
>> + Controller Index: <controller id>
>> + Command Parameters: Address (6 Octets)
>> + Address_Type (1 Octet)
>> + Network_Role (1 Octet)
>> + Return Parameters: Address (6 Octets)
>> + Address_Type (1 Octet)
>> + Network_Role (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 already
>> + enabled, otherwise this command will return a "rejected"
>> + response.
>
> Do we really care if LE is enabled. I mean to some level it is implicit s=
ince you give an LE address. On the other hand, we could just let it progra=
m anything it wants. It just never gets executed if LE gets disabled.
>
> The reason I am saying this is that we do not define what happens to all =
these networks if you later on disable LE. We would have to send events to =
notify about changes.
>
> Refusing LE based entries for a BR/EDR only controller is fine, but if th=
e controller is LE capable we might need to be careful.
>
>> +
>> + 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
>> +
>> + This command generates a Command Complete event on success
>> + or failure.
>> +
>> + Possible errors: Busy
>> + Refused
>> + Invalid Parameters
>> + Not Powered
>> + Invalid Index
>> + Already Connected
>> +
>> +
>> +Remove Network Command
>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> +
>> + Command Code: 0x0044
>> + Controller Index: <controller id>
>> + Command Parameters: Address (6 Octets)
>> + Address_Type (1 Octet)
>> + Network_Role (1 Octet)
>> + Return Parameters: Address (6 Octets)
>> + Address_Type (1 Octet)
>> + Network_Role (1 Octet)
>> +
>> + This command is used to disconnect a network connection from a
>> + remote BTLE node. 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
>> +
>> + This command generates a Command Complete event on success
>> + or failure.
>> +
>> + Possible errors: Busy
>> + Not Connected
>> + Invalid Parameters
>> + Not Powered
>> + Invalid Index
>> +
>> +
>> Command Complete Event
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> @@ -3645,3 +3766,54 @@ Advertising Removed Event
>>
>> The event will only be sent to management sockets other than the
>> one through which the command was sent.
>> +
>> +
>> +Network Added Event
>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> +
>> + Event Code: 0x0025
>> + Controller Index: <controller id>
>> + Event Parameters: Address (6 Octets)
>> + Address_Type (1 Octet)
>> + Network_Role (1 Octet)
>> + Interface Index (4 Octets)
>> +
>> + This event indicates that a network connection to a remote
>> + BTLE node has been established successfully.
>> +
>> + Possible values for the Address_Type parameter:
>> + 1 LE Public
>> + 2 LE Random
>> +
>> + Possible values for the Network_Role parameter:
>> + 1 6LoWPAN Node
>> + 2 6LoWPAN Router
>> +
>> + For devices using resolvable random addresses with a known
>> + identity resolving key, the Address and Address_Type will
>> + contain the identity information.
>> +
>> +
>> +Network Removed Event
>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> +
>> + Event Code: 0x0026
>> + Controller Index: <controller id>
>> + Event Parameters: Address (6 Octets)
>> + Address_Type (1 Octet)
>> + Network_Role (1 Octet)
>> +
>> + This event indicates that the BTLE network connection to a remote
>> + node has been lost.
>> +
>> + Possible values for the Address_Type parameter:
>> + 1 LE Public
>> + 2 LE Random
>> +
>> + Possible values for the Network_Role parameter:
>> + 1 6LoWPAN Node
>> + 2 6LoWPAN Router
>> +
>> + For devices using resolvable random addresses with a known
>> + identity resolving key, the Address and Address_Type will
>> + contain the identity information.
>
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth=
" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--=20
Luiz Augusto von Dentz
Hi Patrik,
> 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.
> + 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.
> +
> + For devices using resolvable random addresses with a known
> + identity resolving key, the Address and Address_Type will
> + contain the identity information.
> +
> + This command can only be used when the controller is powered.
> +
> + This command generates a Command Complete event on success or
> + a Command Status event on failure.
> +
> + Possible errors: Invalid Parameters
> + Not Powered
> + Invalid Index
> +
> +
> +Add Network Command
> +===================
> +
> + Command Code: 0x0043
> + Controller Index: <controller id>
> + Command Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Network_Role (1 Octet)
> + Return Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Network_Role (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 already
> + enabled, otherwise this command will return a "rejected"
> + response.
Do we really care if LE is enabled. I mean to some level it is implicit since you give an LE address. On the other hand, we could just let it program anything it wants. It just never gets executed if LE gets disabled.
The reason I am saying this is that we do not define what happens to all these networks if you later on disable LE. We would have to send events to notify about changes.
Refusing LE based entries for a BR/EDR only controller is fine, but if the controller is LE capable we might need to be careful.
> +
> + 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
> +
> + This command generates a Command Complete event on success
> + or failure.
> +
> + Possible errors: Busy
> + Refused
> + Invalid Parameters
> + Not Powered
> + Invalid Index
> + Already Connected
> +
> +
> +Remove Network Command
> +======================
> +
> + Command Code: 0x0044
> + Controller Index: <controller id>
> + Command Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Network_Role (1 Octet)
> + Return Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Network_Role (1 Octet)
> +
> + This command is used to disconnect a network connection from a
> + remote BTLE node. 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
> +
> + This command generates a Command Complete event on success
> + or failure.
> +
> + Possible errors: Busy
> + Not Connected
> + Invalid Parameters
> + Not Powered
> + Invalid Index
> +
> +
> Command Complete Event
> ======================
>
> @@ -3645,3 +3766,54 @@ Advertising Removed Event
>
> The event will only be sent to management sockets other than the
> one through which the command was sent.
> +
> +
> +Network Added Event
> +===================
> +
> + Event Code: 0x0025
> + Controller Index: <controller id>
> + Event Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Network_Role (1 Octet)
> + Interface Index (4 Octets)
> +
> + This event indicates that a network connection to a remote
> + BTLE node has been established successfully.
> +
> + Possible values for the Address_Type parameter:
> + 1 LE Public
> + 2 LE Random
> +
> + Possible values for the Network_Role parameter:
> + 1 6LoWPAN Node
> + 2 6LoWPAN Router
> +
> + For devices using resolvable random addresses with a known
> + identity resolving key, the Address and Address_Type will
> + contain the identity information.
> +
> +
> +Network Removed Event
> +=====================
> +
> + Event Code: 0x0026
> + Controller Index: <controller id>
> + Event Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Network_Role (1 Octet)
> +
> + This event indicates that the BTLE network connection to a remote
> + node has been lost.
> +
> + Possible values for the Address_Type parameter:
> + 1 LE Public
> + 2 LE Random
> +
> + Possible values for the Network_Role parameter:
> + 1 6LoWPAN Node
> + 2 6LoWPAN Router
> +
> + For devices using resolvable random addresses with a known
> + identity resolving key, the Address and Address_Type will
> + contain the identity information.
Regards
Marcel