* [RFC] doc: Add Management Interface IPSP API definitions
@ 2016-02-18 12:17 Patrik Flykt
2016-02-20 7:59 ` Marcel Holtmann
0 siblings, 1 reply; 5+ messages in thread
From: Patrik Flykt @ 2016-02-18 12:17 UTC (permalink / raw)
To: linux-bluetooth
---
Hi,
Here is an update on the 6lowpan Network Management API posted by Johan
June last year. The proposed Network Management API has now been merged
into the existing Bluetooth Management API with only the 6lowpan
specific commands and events added and updated according to comments,
including a rename to IPSP.
The interface index has been set to 4 octets for those commands that added
one. In the kernel it seems 'int' is used, so some further figuring out
is perhaps needed - or then I just missed something.
Cheers,
Patrik
doc/doc.txt | 0
doc/mgmt-api.txt | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 145 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..34d1736 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -2801,6 +2801,114 @@ Start Limited Discovery Command
Invalid Index
+Connect IPSP Command
+====================
+
+ Command Code: 0x0042
+ Controller Index: <controller id>
+ Command Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+ Return Parameters: Interface Index (4 Octets)
+ Address (6 Octets)
+ Address_Type (1 Octet)
+
+ This command is used to connect to a remote IPSP Node.
+
+ Possible values for the Address_Type parameter:
+ 1 LE Public
+ 2 LE Random
+
+ This command generates a Command Complete event on success
+ or failure.
+
+ Possible errors: Busy
+ Refused
+ Invalid Parameters
+ Not Powered
+ Invalid Index
+ Already Connected
+
+
+Disconnect IPSP 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)
+
+ This command is used to disconnect from a remote IPSP device.
+
+ Possible values for the Address_Type parameter:
+ 1 LE Public
+ 2 LE Random
+
+ This command generates a Command Complete event on success
+ or failure.
+
+ Possible errors: Busy
+ Not Connected
+ Invalid Parameters
+ Not Powered
+ Invalid Index
+
+
+Get IPSP Connections Command
+============================
+
+ Command Code: 0x0044
+ Controller Index: <controller id>
+ Command Parameters:
+ Return Parameters: Interface Index (4 Octets)
+ Connection_Count (2 Octets)
+ Address1 {
+ Address (6 Octets)
+ Address_Type (1 Octet)
+ }
+ Address2 { }
+ ...
+
+ This command is used to retrieve a list of currently connected
+ IPSP devices.
+
+ Possible values for the Address_Type parameter:
+ 1 LE Public
+ 2 LE Random
+
+ 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
+
+
+Enable IPSP Server Command
+==========================
+
+ Command Code: 0x0045
+ Controller Index: <controller id>
+ Command Parameters: Enable (1 Octet)
+ Return Parameters:
+
+ This command is used start a IPSP Server (Node rols) on a
+ specified controller.
+
+ This command generates a Command Complete event on success or
+ a Command Status event on failure.
+
+ Possible errors: Busy
+ Invalid Index
+
+
Command Complete Event
======================
@@ -3645,3 +3753,40 @@ Advertising Removed Event
The event will only be sent to management sockets other than the
one through which the command was sent.
+
+
+IPSP Connected Event
+====================
+
+ Event Code: 0x0025
+ Controller Index: <controller id>
+ Event Parameters: Interface Index (4 Octets)
+ Address (6 Octets)
+ Address_Type (1 Octet)
+
+ This event indicates that a successful IPSP connection has
+ been created to the remote device.
+
+ For devices using resolvable random addresses with a known
+ identity resolving key, the Address and Address_Type will
+ contain the identity information.
+
+
+IPSP Disconnected Event
+=======================
+
+ Event Code: 0x0026
+ Controller Index: <controller id>
+ Event Parameters: Address (6 Octets)
+ Address_Type (1 Octet)
+
+ This event indicates that the IPSP connection was lost to a
+ remote device.
+
+ Possible values for the Address_Type parameter:
+ 1 LE Public
+ 2 LE Random
+
+ 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
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [RFC] doc: Add Management Interface IPSP API definitions
2016-02-18 12:17 [RFC] doc: Add Management Interface IPSP API definitions Patrik Flykt
@ 2016-02-20 7:59 ` Marcel Holtmann
2016-02-22 13:02 ` Patrik Flykt
0 siblings, 1 reply; 5+ messages in thread
From: Marcel Holtmann @ 2016-02-20 7:59 UTC (permalink / raw)
To: Patrik Flykt; +Cc: linux-bluetooth
Hi Patrik,
> Here is an update on the 6lowpan Network Management API posted by Johan
> June last year. The proposed Network Management API has now been merged
> into the existing Bluetooth Management API with only the 6lowpan
> specific commands and events added and updated according to comments,
> including a rename to IPSP.
>
> The interface index has been set to 4 octets for those commands that added
> one. In the kernel it seems 'int' is used, so some further figuring out
> is perhaps needed - or then I just missed something.
>
>
> Cheers,
>
> Patrik
>
> doc/doc.txt | 0
> doc/mgmt-api.txt | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 145 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..34d1736 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -2801,6 +2801,114 @@ Start Limited Discovery Command
> Invalid Index
>
>
> +Connect IPSP Command
> +====================
> +
> + Command Code: 0x0042
> + Controller Index: <controller id>
> + Command Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> + Return Parameters: Interface Index (4 Octets)
> + Address (6 Octets)
> + Address_Type (1 Octet)
I think you really want to swap this. Address + Type first and then Interface Index.
> +
> + This command is used to connect to a remote IPSP Node.
> +
> + Possible values for the Address_Type parameter:
> + 1 LE Public
> + 2 LE Random
> +
> + This command generates a Command Complete event on success
> + or failure.
> +
> + Possible errors: Busy
> + Refused
> + Invalid Parameters
> + Not Powered
> + Invalid Index
> + Already Connected
> +
> +
> +Disconnect IPSP 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)
> +
> + This command is used to disconnect from a remote IPSP device.
> +
> + Possible values for the Address_Type parameter:
> + 1 LE Public
> + 2 LE Random
I actually prefer that we list 0 value as reserved like we have done for the other LE only commands.
In addition we might want to make clear that these commands are only supported if LE is actually enabled first.
> +
> + This command generates a Command Complete event on success
> + or failure.
> +
> + Possible errors: Busy
> + Not Connected
> + Invalid Parameters
> + Not Powered
> + Invalid Index
> +
> +
> +Get IPSP Connections Command
> +============================
> +
> + Command Code: 0x0044
> + Controller Index: <controller id>
> + Command Parameters:
> + Return Parameters: Interface Index (4 Octets)
> + Connection_Count (2 Octets)
> + Address1 {
> + Address (6 Octets)
> + Address_Type (1 Octet)
> + }
> + Address2 { }
> + ...
I would normally assume that the Get Connections one comes before the Connect / Disconnect commands.
> +
> + This command is used to retrieve a list of currently connected
> + IPSP devices.
> +
> + Possible values for the Address_Type parameter:
> + 1 LE Public
> + 2 LE Random
> +
> + 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
> +
> +
> +Enable IPSP Server Command
> +==========================
> +
> + Command Code: 0x0045
> + Controller Index: <controller id>
> + Command Parameters: Enable (1 Octet)
> + Return Parameters:
Not a big fan of the command name. We never used the Enable Something term.
> +
> + This command is used start a IPSP Server (Node rols) on a
> + specified controller.
> +
> + This command generates a Command Complete event on success or
> + a Command Status event on failure.
> +
> + Possible errors: Busy
> + Invalid Index
> +
> +
> Command Complete Event
> ======================
>
> @@ -3645,3 +3753,40 @@ Advertising Removed Event
>
> The event will only be sent to management sockets other than the
> one through which the command was sent.
> +
> +
> +IPSP Connected Event
> +====================
> +
> + Event Code: 0x0025
> + Controller Index: <controller id>
> + Event Parameters: Interface Index (4 Octets)
> + Address (6 Octets)
> + Address_Type (1 Octet)
Same here. I think they are in the wrong order.
> +
> + This event indicates that a successful IPSP connection has
> + been created to the remote device.
> +
> + For devices using resolvable random addresses with a known
> + identity resolving key, the Address and Address_Type will
> + contain the identity information.
> +
> +
> +IPSP Disconnected Event
> +=======================
> +
> + Event Code: 0x0026
> + Controller Index: <controller id>
> + Event Parameters: Address (6 Octets)
> + Address_Type (1 Octet)
> +
> + This event indicates that the IPSP connection was lost to a
> + remote device.
> +
> + Possible values for the Address_Type parameter:
> + 1 LE Public
> + 2 LE Random
> +
> + For devices using resolvable random addresses with a known
> + identity resolving key, the Address and Address_Type will
> + contain the identity information.
I am not a huge fan of the IPSP in the commands and events. Can we find something better?
Regards
Marcel
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC] doc: Add Management Interface IPSP API definitions
2016-02-20 7:59 ` Marcel Holtmann
@ 2016-02-22 13:02 ` Patrik Flykt
2016-02-22 13:42 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 5+ messages in thread
From: Patrik Flykt @ 2016-02-22 13:02 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
Hi,
On Fri, 2016-02-19 at 23:59 -0800, Marcel Holtmann wrote:
> > +Connect IPSP Command
> > +====================
> > +
> > + Command Code: 0x0042
> > + Controller Index: <controller id>
> > + Command Parameters: Address (6 Octets)
> > + Address_Type (1 Octet)
> > + Return Parameters: Interface Index (4 Octets)
> > + Address (6 Octets)
> > + Address_Type (1 Octet)
>
> I think you really want to swap this. Address + Type first and then
> Interface Index.
Ok.
> > + This command is used to connect to a remote IPSP Node.
> > +
> > + Possible values for the Address_Type parameter:
> > + 1 LE Public
> > + 2 LE Random
> > +
> > + This command generates a Command Complete event on success
> > + or failure.
> > +
> > + Possible errors: Busy
> > + Refused
> > + Invalid Parameters
> > + Not Powered
> > + Invalid Index
> > + Already Connected
> > +
> > +
> > +Disconnect IPSP 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)
> > +
> > + This command is used to disconnect from a remote IPSP device.
> > +
> > + Possible values for the Address_Type parameter:
> > + 1 LE Public
> > + 2 LE Random
>
> I actually prefer that we list 0 value as reserved like we have done
> for the other LE only commands.
>
> In addition we might want to make clear that these commands are only
> supported if LE is actually enabled first.
Ok.
> > +Get IPSP Connections Command
> > +============================
> > +
> > + Command Code: 0x0044
> > + Controller Index: <controller id>
> > + Command Parameters:
> > + Return Parameters: Interface Index (4 Octets)
> > + Connection_Count (2 Octets)
> > + Address1 {
> > + Address (6 Octets)
> > + Address_Type (1 Octet)
> > + }
> > + Address2 { }
> > + ...
>
> I would normally assume that the Get Connections one comes before the
> Connect / Disconnect commands.
Swapped order here.
> > +
> > + This command is used to retrieve a list of currently connected
> > + IPSP devices.
> > +
> > + Possible values for the Address_Type parameter:
> > + 1 LE Public
> > + 2 LE Random
> > +
> > + 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
> > +
> > +
> > +Enable IPSP Server Command
> > +==========================
> > +
> > + Command Code: 0x0045
> > + Controller Index: <controller id>
> > + Command Parameters: Enable (1 Octet)
> > + Return Parameters:
>
> Not a big fan of the command name. We never used the Enable Something
> term.
Is 'Set IPSP Node Role Command' ok?
> > +IPSP Connected Event
> > +====================
> > +
> > + Event Code: 0x0025
> > + Controller Index: <controller id>
> > + Event Parameters: Interface Index (4 Octets)
> > + Address (6 Octets)
> > + Address_Type (1 Octet)
>
> Same here. I think they are in the wrong order.
Ok.
> > +IPSP Disconnected Event
> > +=======================
> > +
> > + Event Code: 0x0026
> > + Controller Index: <controller id>
> > + Event Parameters: Address (6 Octets)
> > + Address_Type (1 Octet)
> > +
> > + This event indicates that the IPSP connection was lost to a
> > + remote device.
> > +
> > + Possible values for the Address_Type parameter:
> > + 1 LE Public
> > + 2 LE Random
> > +
> > + For devices using resolvable random addresses with a known
> > + identity resolving key, the Address and Address_Type will
> > + contain the identity information.
>
> I am not a huge fan of the IPSP in the commands and events. Can we
> find something better?
There was a discussion on naming in "Re: [RFC v3] doc: Add initial
Network Management API definition" on the mailing list last June that
ended a bit inconclusive. Meanwhile RFC 7668 has gravitated towards
using "6LowPAN techniques" to describe how IPv6 is transported over
BTLE, but the RFC itself is called "IPv6 over BLUETOOTH(R) Low Energy".
Then again include/net/bluetooth/l2cap.h defines a value called
L2CAP_PSM_IPSP.
Shall we continue using 6lowpan as before in RFC v3?
Cheers,
Patrik
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC] doc: Add Management Interface IPSP API definitions
2016-02-22 13:02 ` Patrik Flykt
@ 2016-02-22 13:42 ` Luiz Augusto von Dentz
2016-02-24 11:30 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 5+ messages in thread
From: Luiz Augusto von Dentz @ 2016-02-22 13:42 UTC (permalink / raw)
To: Patrik Flykt; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
Hi Patrik, Marcel,
On Mon, Feb 22, 2016 at 3:02 PM, Patrik Flykt
<Patrik.Flykt@linux.intel.com> wrote:
>
> Hi,
>
> On Fri, 2016-02-19 at 23:59 -0800, Marcel Holtmann wrote:
>> > +Connect IPSP Command
>> > +====================
>> > +
>> > + Command Code: 0x0042
>> > + Controller Index: <controller id>
>> > + Command Parameters: Address (6 Octets)
>> > + Address_Type (1 Octet)
>> > + Return Parameters: Interface Index (4 Octets)
>> > + Address (6 Octets)
>> > + Address_Type (1 Octet)
>>
>> I think you really want to swap this. Address + Type first and then
>> Interface Index.
>
> Ok.
>
>> > + This command is used to connect to a remote IPSP Node.
>> > +
>> > + Possible values for the Address_Type parameter:
>> > + 1 LE Public
>> > + 2 LE Random
>> > +
>> > + This command generates a Command Complete event on success
>> > + or failure.
>> > +
>> > + Possible errors: Busy
>> > + Refused
>> > + Invalid Parameters
>> > + Not Powered
>> > + Invalid Index
>> > + Already Connected
>> > +
>> > +
>> > +Disconnect IPSP 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)
>> > +
>> > + This command is used to disconnect from a remote IPSP device.
>> > +
>> > + Possible values for the Address_Type parameter:
>> > + 1 LE Public
>> > + 2 LE Random
>>
>> I actually prefer that we list 0 value as reserved like we have done
>> for the other LE only commands.
>>
>> In addition we might want to make clear that these commands are only
>> supported if LE is actually enabled first.
>
> Ok.
>
>> > +Get IPSP Connections Command
>> > +============================
>> > +
>> > + Command Code: 0x0044
>> > + Controller Index: <controller id>
>> > + Command Parameters:
>> > + Return Parameters: Interface Index (4 Octets)
>> > + Connection_Count (2 Octets)
>> > + Address1 {
>> > + Address (6 Octets)
>> > + Address_Type (1 Octet)
>> > + }
>> > + Address2 { }
>> > + ...
>>
>> I would normally assume that the Get Connections one comes before the
>> Connect / Disconnect commands.
>
> Swapped order here.
>
>> > +
>> > + This command is used to retrieve a list of currently connected
>> > + IPSP devices.
>> > +
>> > + Possible values for the Address_Type parameter:
>> > + 1 LE Public
>> > + 2 LE Random
>> > +
>> > + 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
>> > +
>> > +
>> > +Enable IPSP Server Command
>> > +==========================
>> > +
>> > + Command Code: 0x0045
>> > + Controller Index: <controller id>
>> > + Command Parameters: Enable (1 Octet)
>> > + Return Parameters:
>>
>> Not a big fan of the command name. We never used the Enable Something
>> term.
>
> Is 'Set IPSP Node Role Command' ok?
Btw what exactly is this command suppose to do? Just add a listening
channel or does it actually enables advertising? How do we actually
hook with the agent to authorize incoming connections? Perhaps it
actually a better idea to use the L2CAP socket API for this and make
bluetoothd listen on PSM 35 like we do for other sockets, once the
connection is authorized then we can have a mgmt command to add it to
the network interface, actually this may as well replace the
Connect/Disconnect commands with Add/Remove client so the connection
phase is actually handled by bluetoothd.
>
>> > +IPSP Connected Event
>> > +====================
>> > +
>> > + Event Code: 0x0025
>> > + Controller Index: <controller id>
>> > + Event Parameters: Interface Index (4 Octets)
>> > + Address (6 Octets)
>> > + Address_Type (1 Octet)
>>
>> Same here. I think they are in the wrong order.
>
> Ok.
>
>> > +IPSP Disconnected Event
>> > +=======================
>> > +
>> > + Event Code: 0x0026
>> > + Controller Index: <controller id>
>> > + Event Parameters: Address (6 Octets)
>> > + Address_Type (1 Octet)
>> > +
>> > + This event indicates that the IPSP connection was lost to a
>> > + remote device.
>> > +
>> > + Possible values for the Address_Type parameter:
>> > + 1 LE Public
>> > + 2 LE Random
>> > +
>> > + For devices using resolvable random addresses with a known
>> > + identity resolving key, the Address and Address_Type will
>> > + contain the identity information.
>>
>> I am not a huge fan of the IPSP in the commands and events. Can we
>> find something better?
>
> There was a discussion on naming in "Re: [RFC v3] doc: Add initial
> Network Management API definition" on the mailing list last June that
> ended a bit inconclusive. Meanwhile RFC 7668 has gravitated towards
> using "6LowPAN techniques" to describe how IPv6 is transported over
> BTLE, but the RFC itself is called "IPv6 over BLUETOOTH(R) Low Energy".
>
> Then again include/net/bluetooth/l2cap.h defines a value called
> L2CAP_PSM_IPSP.
>
> Shall we continue using 6lowpan as before in RFC v3?
>
>
> Cheers,
>
> Patrik
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [RFC] doc: Add Management Interface IPSP API definitions
2016-02-22 13:42 ` Luiz Augusto von Dentz
@ 2016-02-24 11:30 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 5+ messages in thread
From: Luiz Augusto von Dentz @ 2016-02-24 11:30 UTC (permalink / raw)
To: Patrik Flykt; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
Hi Marcel,
On Mon, Feb 22, 2016 at 3:42 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Patrik, Marcel,
>
> On Mon, Feb 22, 2016 at 3:02 PM, Patrik Flykt
> <Patrik.Flykt@linux.intel.com> wrote:
>>
>> Hi,
>>
>> On Fri, 2016-02-19 at 23:59 -0800, Marcel Holtmann wrote:
>>> > +Connect IPSP Command
>>> > +====================
>>> > +
>>> > + Command Code: 0x0042
>>> > + Controller Index: <controller id>
>>> > + Command Parameters: Address (6 Octets)
>>> > + Address_Type (1 Octet)
>>> > + Return Parameters: Interface Index (4 Octets)
>>> > + Address (6 Octets)
>>> > + Address_Type (1 Octet)
>>>
>>> I think you really want to swap this. Address + Type first and then
>>> Interface Index.
>>
>> Ok.
>>
>>> > + This command is used to connect to a remote IPSP Node.
>>> > +
>>> > + Possible values for the Address_Type parameter:
>>> > + 1 LE Public
>>> > + 2 LE Random
>>> > +
>>> > + This command generates a Command Complete event on success
>>> > + or failure.
>>> > +
>>> > + Possible errors: Busy
>>> > + Refused
>>> > + Invalid Parameters
>>> > + Not Powered
>>> > + Invalid Index
>>> > + Already Connected
>>> > +
>>> > +
>>> > +Disconnect IPSP 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)
>>> > +
>>> > + This command is used to disconnect from a remote IPSP device.
>>> > +
>>> > + Possible values for the Address_Type parameter:
>>> > + 1 LE Public
>>> > + 2 LE Random
>>>
>>> I actually prefer that we list 0 value as reserved like we have done
>>> for the other LE only commands.
>>>
>>> In addition we might want to make clear that these commands are only
>>> supported if LE is actually enabled first.
>>
>> Ok.
>>
>>> > +Get IPSP Connections Command
>>> > +============================
>>> > +
>>> > + Command Code: 0x0044
>>> > + Controller Index: <controller id>
>>> > + Command Parameters:
>>> > + Return Parameters: Interface Index (4 Octets)
>>> > + Connection_Count (2 Octets)
>>> > + Address1 {
>>> > + Address (6 Octets)
>>> > + Address_Type (1 Octet)
>>> > + }
>>> > + Address2 { }
>>> > + ...
>>>
>>> I would normally assume that the Get Connections one comes before the
>>> Connect / Disconnect commands.
>>
>> Swapped order here.
>>
>>> > +
>>> > + This command is used to retrieve a list of currently connected
>>> > + IPSP devices.
>>> > +
>>> > + Possible values for the Address_Type parameter:
>>> > + 1 LE Public
>>> > + 2 LE Random
>>> > +
>>> > + 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
>>> > +
>>> > +
>>> > +Enable IPSP Server Command
>>> > +==========================
>>> > +
>>> > + Command Code: 0x0045
>>> > + Controller Index: <controller id>
>>> > + Command Parameters: Enable (1 Octet)
>>> > + Return Parameters:
>>>
>>> Not a big fan of the command name. We never used the Enable Something
>>> term.
>>
>> Is 'Set IPSP Node Role Command' ok?
>
> Btw what exactly is this command suppose to do? Just add a listening
> channel or does it actually enables advertising? How do we actually
> hook with the agent to authorize incoming connections? Perhaps it
> actually a better idea to use the L2CAP socket API for this and make
> bluetoothd listen on PSM 35 like we do for other sockets, once the
> connection is authorized then we can have a mgmt command to add it to
> the network interface, actually this may as well replace the
> Connect/Disconnect commands with Add/Remove client so the connection
> phase is actually handled by bluetoothd.
Any feedback regarding this? I think it becomes a little more trivial
to leave the connection management up to the userspace using the
traditional socket API and leave only the network interface management
to the kernel to deal with, thus we don't need to duplicate any of
socket API in the management interface.
>>
>>> > +IPSP Connected Event
>>> > +====================
>>> > +
>>> > + Event Code: 0x0025
>>> > + Controller Index: <controller id>
>>> > + Event Parameters: Interface Index (4 Octets)
>>> > + Address (6 Octets)
>>> > + Address_Type (1 Octet)
>>>
>>> Same here. I think they are in the wrong order.
>>
>> Ok.
>>
>>> > +IPSP Disconnected Event
>>> > +=======================
>>> > +
>>> > + Event Code: 0x0026
>>> > + Controller Index: <controller id>
>>> > + Event Parameters: Address (6 Octets)
>>> > + Address_Type (1 Octet)
>>> > +
>>> > + This event indicates that the IPSP connection was lost to a
>>> > + remote device.
>>> > +
>>> > + Possible values for the Address_Type parameter:
>>> > + 1 LE Public
>>> > + 2 LE Random
>>> > +
>>> > + For devices using resolvable random addresses with a known
>>> > + identity resolving key, the Address and Address_Type will
>>> > + contain the identity information.
>>>
>>> I am not a huge fan of the IPSP in the commands and events. Can we
>>> find something better?
>>
>> There was a discussion on naming in "Re: [RFC v3] doc: Add initial
>> Network Management API definition" on the mailing list last June that
>> ended a bit inconclusive. Meanwhile RFC 7668 has gravitated towards
>> using "6LowPAN techniques" to describe how IPv6 is transported over
>> BTLE, but the RFC itself is called "IPv6 over BLUETOOTH(R) Low Energy".
>>
>> Then again include/net/bluetooth/l2cap.h defines a value called
>> L2CAP_PSM_IPSP.
>>
>> Shall we continue using 6lowpan as before in RFC v3?
>>
>>
>> Cheers,
>>
>> Patrik
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-02-24 11:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-18 12:17 [RFC] doc: Add Management Interface IPSP API definitions Patrik Flykt
2016-02-20 7:59 ` Marcel Holtmann
2016-02-22 13:02 ` Patrik Flykt
2016-02-22 13:42 ` Luiz Augusto von Dentz
2016-02-24 11:30 ` Luiz Augusto von Dentz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).