Re: [RFC] Exposing network credentials to an application

[Drew Stebbins]

Thanks Grant for the reply. The config option sounds right to me as a
general solution. Connman folks, thoughts?

Thanks,

Drew


On Fri, Jun 27, 2014 at 12:27 PM, Grant Erickson 
wrote:

> On Jun 27, 2014, at 12:00 PM, Jukka Rissanen <
> jukka.rissa...@linux.intel.com> wrote:
> > On to, 2014-06-26 at 16:52 -0700, Drew Stebbins wrote:
> >> Hi folks,
> >>
> >> I'm working on a project where devices on a WiFi network must
> occasionally
> >> provide an application with the WiFi network's security credentials.
> These
> >> credentials are used to provision new devices via an alternate
> >> communication mechanism. For consistency's sake, I'd like for the
> >> application to get these credentials from ConnMan via D-Bus. For now,
> I've
> >> added a "Passphrase" property back to the D-Bus service dictionary for
> WiFi
> >> networks. This property was previously removed back in commit
> >> eff06f8e1ce3c3dcf5a3d8158d01403ecf6d62a8.
> >
> > Although the Passphrase is not very secret information it was too easy
> > to get it via dbus without any apparent real use case in mind. That is
> > probably why it was removed from dubs.
>
> Certainly the one use case that was prevalent around the time of this
> refactor was agent support. In the particular use case where an old PSK
> fails and the agent interface prompts the client for a new one, the old PSK
> is provided in an adjunct dictionary for the purposes of rendering it
> directly or substituted by bullets (•) in a GUI.
>
> >> The above commit would seem to imply that sensitive information such as
> >> passphrases should be kept out of the publicly-visible service
> dictionary.
> >> If so, how would the community suggest ConnMan expose network
> credentials
> >> to an application? I'd like to upstream this functionality if at all
> >> possible, as I suspect I'm not the only one with this sort of use case.
> >
> > What kind of use case you have in mind? Also note that most people would
> > probably not want to expose this information via dubs.
> >
> > If you are really eager to get passphrase information, you can always
> > dig the settings files in /var/lib/connman directory.
>
> Imagine a deeply-embedded system with WiFi in which there is no physical
> user interface on the device whatsoever. Now, imagine an out-of-band
> channel in which a mobile device, with appropriate authorization over that
> out-of-band channel, would like to extract the currently-provisioned WiFi
> services for the purposes of provisioning another new system.
>
> Imagine another system, different from a mobile device, perhaps like the
> first that can communicate and authenticate with it out-of-band, based on
> some provided user authority. Over that channel, the first device would
> like to tell the second, "When you encounter this WiFi network, you may
> connect to it with these credentials.".
>
> While you're correct that one could certainly root about int he
> /var/lib/connman directory and pull this, such a mechanism will not survive
> connman version changes due to a high-reliance on internal details that are
> subject to change by virtue of being not being part of connman's public API.
>
> Perhaps there could be a config option, deserted by default, that allows
> this property to be exposed when that configuration is asserted?
>
> Best,
>
> Grant
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: Static IP on unconnected wired port?

[Mike Purvis]

Hi,

I'm now running 1.24.

It looks like I have /var/lib/connman/settings file which resembles
"example.config" file supplied in the documentation. However, having added
an item to it, no behaviour seems to change.

[global]
OfflineMode=false

[Wired]
Enable=true
Tethering=false

[WiFi]
Enable=true
Tethering=false

[Bluetooth]
Enable=true
Tethering=false

[service_xyz]
Type=ethernet
IPv4=192.168.1.1/255.255.255.0

According to connmand -h, though, the default config location is actually
/etc/connman/main.conf— so I copied the settings file (with my addition) to
that file, and then started the daemon in the foreground. Looks like it's
actually reading the file now, but not able to act on it:

administrator@jackal:/etc/connman$ sudo connmand -n
connmand[4245]: Connection Manager version 1.24
connmand[4245]: Unknown group global in main.conf
connmand[4245]: Unknown group Wired in main.conf
connmand[4245]: Unknown group WiFi in main.conf
connmand[4245]: Unknown group Bluetooth in main.conf
connmand[4245]: Unknown group service_xyz in main.conf
connmand[4245]: Checking loopback interface settings

I also tried moving my service definition to
/var/lib/connman/example.config, but this registered no response either.

In the short term, I've used the -I flag to allow me to set the static IP
of this device using /etc/network/interfaces, which seems to work okay.
However, I'd like to understand how to set this using connman's
configuration.

Thanks,

Mike


On 7 July 2014 07:54, Jukka Rissanen  wrote:

> Hi Mike,
>
> On ma, 2014-07-07 at 07:41 -0400, Mike Purvis wrote:
> > Hi Jukka,
> >
> >
> > Very helpful, thanks— not sure why it didn't occur to me to look in
> > the source repo itself for docs. For others following along, the
> > config file documentation is
> > here:
> http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt
> >
> >
> > Is there a PPA or other debian source for getting the currently
> > recommended connman version, or is it basically down to building it
> > from source?
>
> I am not using debian and anyway build connman from source. If you want
> to build from sources in debian, the latest scripts can be found at
> https://github.com/pfl/connman-deb
>
> >
> >
> > Looks like 1.21 is the version currently in sid, so that one can be
> > had as a sourcedeb without much trouble. Is that adequate, or is it
> > best to be right on the current release?
>
> If you have a choice, then I would suggest using the very latest
> version. We try hard to keep the released versions in good shape so it
> is safe to take the latest version.
>
>
> Cheers,
> Jukka
>
>
>
> >
> >
> > Thanks again,
> >
> >
> > Mike
> >
> >
> > On 7 July 2014 03:58, Jukka Rissanen 
> > wrote:
> > Hi Mike,
> >
> > On pe, 2014-07-04 at 13:45 -0400, Mike Purvis wrote:
> > > Hey all,
> > >
> > > I have a platform where I'd like an ethernet port to come up
> > with a static
> > > IP, much as it does with /etc/network/interfaces containing:
> > >
> > > auto p5p1
> > > iface p5p1 inet static
> > >   address 192.168.54.1
> > >   netmask 255.255.255.0
> > >
> > > This is essential so that a user can set a static IP on
> > their laptop, and
> > > then SSH into the device in order to configure the wireless,
> > etc.
> > >
> > > However, it doesn't seem possible to do this under connman—
> > without a wire
> > > connected to the ethernet port, no wired services are shown,
> > so I have no
> > > opportunity to do:
> > >
> > > connmanctl config  --ipv4 ...
> > >
> > > Is there a way to do this which I'm not seeing?
> >
> >
> > Yes, there is limited workaround so you can create a .config
> > file that
> > setups the ethernet port automatically when it comes up. See
> > doc/config-format.txt in connman sources for details. Note
> > that a
> > service becomes immutable if provisioned via .config file so
> > user is
> > only able to tweak very limited settings for the service in
> > this case.
> >
> > >  Alternatively, can connman
> > > be set up to ignore my ethernet port and manage only the
> > wifi?
> >
> >
> > Yes, you can start connman with -I command line option to
> > ignore some
> > network interfaces.
> >
> > >
> > > I apologize for the elementary question— the best docs I've
> > been able to
> > > find are those on the Arch Linux wiki:
> > > https://wiki.archlinux.org/index.php/Connman
> > >
> > > I'm using connman v1.15, via the Ubuntu 14.04 deb package.
> >
> >
> > Please upgrade connman if possible, we have fixed lot of nasty
> > bugs
> > after 1.15.
> >
> >
> > Cheers,
> > Jukka
> >
> >
> >
> 

Re: More detailed wifi service information

[meh.]

On Mon, Jul 07, 2014 at 04:49:51PM +0300, Tomasz Bursztyka wrote:
> ConnMan make services based on SSID and security specs (wep, wpa/wpa2,
> etc...).
> So if 2 AP shares the same SSID but with different security specs, connman
> will create
> 2 distinct services.
> 
> Now if this 2 APs have hidden SSIDs but still different specs: same thing, 2
> "hidden" services.
> 
> In case they both have same security specs, only 1 "hidden" service is
> shown.
> The differentiation will be made while getting connected, since the user
> provides the proper
> SSID and the credentials (all that through Agent API).

That makes sense, thanks!


pgphkJH158WJW.pgp
Description: PGP signature
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: More detailed wifi service information

[Tomasz Bursztyka]

Hi,


What about hidden SSIDs? Is a single hidden network shown in the list?

If not how can a user understand which one is the one he wants to
connect to?


ConnMan make services based on SSID and security specs (wep, wpa/wpa2, 
etc...).
So if 2 AP shares the same SSID but with different security specs, 
connman will create

2 distinct services.

Now if this 2 APs have hidden SSIDs but still different specs: same 
thing, 2 "hidden" services.


In case they both have same security specs, only 1 "hidden" service is 
shown.
The differentiation will be made while getting connected, since the user 
provides the proper

SSID and the credentials (all that through Agent API).

Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: Static IP on unconnected wired port?

[Jukka Rissanen]

Hi Mike,

On ma, 2014-07-07 at 07:41 -0400, Mike Purvis wrote:
> Hi Jukka,
> 
> 
> Very helpful, thanks— not sure why it didn't occur to me to look in
> the source repo itself for docs. For others following along, the
> config file documentation is
> here: 
> http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt
> 
> 
> Is there a PPA or other debian source for getting the currently
> recommended connman version, or is it basically down to building it
> from source?

I am not using debian and anyway build connman from source. If you want
to build from sources in debian, the latest scripts can be found at
https://github.com/pfl/connman-deb

> 
> 
> Looks like 1.21 is the version currently in sid, so that one can be
> had as a sourcedeb without much trouble. Is that adequate, or is it
> best to be right on the current release?

If you have a choice, then I would suggest using the very latest
version. We try hard to keep the released versions in good shape so it
is safe to take the latest version.


Cheers,
Jukka



> 
> 
> Thanks again,
> 
> 
> Mike
> 
> 
> On 7 July 2014 03:58, Jukka Rissanen 
> wrote:
> Hi Mike,
> 
> On pe, 2014-07-04 at 13:45 -0400, Mike Purvis wrote:
> > Hey all,
> >
> > I have a platform where I'd like an ethernet port to come up
> with a static
> > IP, much as it does with /etc/network/interfaces containing:
> >
> > auto p5p1
> > iface p5p1 inet static
> >   address 192.168.54.1
> >   netmask 255.255.255.0
> >
> > This is essential so that a user can set a static IP on
> their laptop, and
> > then SSH into the device in order to configure the wireless,
> etc.
> >
> > However, it doesn't seem possible to do this under connman—
> without a wire
> > connected to the ethernet port, no wired services are shown,
> so I have no
> > opportunity to do:
> >
> > connmanctl config  --ipv4 ...
> >
> > Is there a way to do this which I'm not seeing?
> 
> 
> Yes, there is limited workaround so you can create a .config
> file that
> setups the ethernet port automatically when it comes up. See
> doc/config-format.txt in connman sources for details. Note
> that a
> service becomes immutable if provisioned via .config file so
> user is
> only able to tweak very limited settings for the service in
> this case.
> 
> >  Alternatively, can connman
> > be set up to ignore my ethernet port and manage only the
> wifi?
> 
> 
> Yes, you can start connman with -I command line option to
> ignore some
> network interfaces.
> 
> >
> > I apologize for the elementary question— the best docs I've
> been able to
> > find are those on the Arch Linux wiki:
> > https://wiki.archlinux.org/index.php/Connman
> >
> > I'm using connman v1.15, via the Ubuntu 14.04 deb package.
> 
> 
> Please upgrade connman if possible, we have fixed lot of nasty
> bugs
> after 1.15.
> 
> 
> Cheers,
> Jukka
> 
> 
> 
> 


___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: More detailed wifi service information

[meh.]

On Mon, Jul 07, 2014 at 10:46:55AM +0300, Tomasz Bursztyka wrote:
> There is already (with newer version of connman) a nice CLI client named
> connmanctl.
> You  might want to check it.

Yeah, I know about it, it's not fancy enough for me.

> ConnMan hides whatever information which is never required for the end-user
> and for the UI
> itself. No-one needs the BSSID or the channel, seriously. This is up to the
> wifi daemon and/or
> the network management daemon (connman here) to handle such information
> relevantly.
> 
> About BSSID, if you have 2+ AP sharing the same network (same SSID, same
> security,
> different channels) ConnMan will still show 1 network (and not 2+ BSSID
> entries).
> The user should not care what AP to select precisely: ConnMan and - in this
> case -
> Wpa_supplicant will ensure he gets connected to the best AP among those
> (strongest signal, lowest noise, so it will pick up the proper AP/Channel).

What about hidden SSIDs? Is a single hidden network shown in the list?

If not how can a user understand which one is the one he wants to
connect to?


pgppHhx1phP8E.pgp
Description: PGP signature
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: Static IP on unconnected wired port?

[Mike Purvis]

Hi Jukka,

Very helpful, thanks— not sure why it didn't occur to me to look in the
source repo itself for docs. For others following along, the config file
documentation is here:
http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt

Is there a PPA or other debian source for getting the currently recommended
connman version, or is it basically down to building it from source?

Looks like 1.21 is the version currently in sid, so that one can be had as
a sourcedeb without much trouble. Is that adequate, or is it best to be
right on the current release?

Thanks again,

Mike


On 7 July 2014 03:58, Jukka Rissanen  wrote:

> Hi Mike,
>
> On pe, 2014-07-04 at 13:45 -0400, Mike Purvis wrote:
> > Hey all,
> >
> > I have a platform where I'd like an ethernet port to come up with a
> static
> > IP, much as it does with /etc/network/interfaces containing:
> >
> > auto p5p1
> > iface p5p1 inet static
> >   address 192.168.54.1
> >   netmask 255.255.255.0
> >
> > This is essential so that a user can set a static IP on their laptop, and
> > then SSH into the device in order to configure the wireless, etc.
> >
> > However, it doesn't seem possible to do this under connman— without a
> wire
> > connected to the ethernet port, no wired services are shown, so I have no
> > opportunity to do:
> >
> > connmanctl config  --ipv4 ...
> >
> > Is there a way to do this which I'm not seeing?
>
> Yes, there is limited workaround so you can create a .config file that
> setups the ethernet port automatically when it comes up. See
> doc/config-format.txt in connman sources for details. Note that a
> service becomes immutable if provisioned via .config file so user is
> only able to tweak very limited settings for the service in this case.
>
> >  Alternatively, can connman
> > be set up to ignore my ethernet port and manage only the wifi?
>
> Yes, you can start connman with -I command line option to ignore some
> network interfaces.
>
> >
> > I apologize for the elementary question— the best docs I've been able to
> > find are those on the Arch Linux wiki:
> > https://wiki.archlinux.org/index.php/Connman
> >
> > I'm using connman v1.15, via the Ubuntu 14.04 deb package.
>
> Please upgrade connman if possible, we have fixed lot of nasty bugs
> after 1.15.
>
>
> Cheers,
> Jukka
>
>
>
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: Static IP on unconnected wired port?

[Jukka Rissanen]

Hi Mike,

On pe, 2014-07-04 at 13:45 -0400, Mike Purvis wrote:
> Hey all,
> 
> I have a platform where I'd like an ethernet port to come up with a static
> IP, much as it does with /etc/network/interfaces containing:
> 
> auto p5p1
> iface p5p1 inet static
>   address 192.168.54.1
>   netmask 255.255.255.0
> 
> This is essential so that a user can set a static IP on their laptop, and
> then SSH into the device in order to configure the wireless, etc.
> 
> However, it doesn't seem possible to do this under connman— without a wire
> connected to the ethernet port, no wired services are shown, so I have no
> opportunity to do:
> 
> connmanctl config  --ipv4 ...
> 
> Is there a way to do this which I'm not seeing?

Yes, there is limited workaround so you can create a .config file that
setups the ethernet port automatically when it comes up. See
doc/config-format.txt in connman sources for details. Note that a
service becomes immutable if provisioned via .config file so user is
only able to tweak very limited settings for the service in this case.

>  Alternatively, can connman
> be set up to ignore my ethernet port and manage only the wifi?

Yes, you can start connman with -I command line option to ignore some
network interfaces.

> 
> I apologize for the elementary question— the best docs I've been able to
> find are those on the Arch Linux wiki:
> https://wiki.archlinux.org/index.php/Connman
> 
> I'm using connman v1.15, via the Ubuntu 14.04 deb package.

Please upgrade connman if possible, we have fixed lot of nasty bugs
after 1.15.


Cheers,
Jukka


___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: More detailed wifi service information

[Tomasz Bursztyka]

Hi,


Hello, found out about connman after having some problems with
connecting to a network with wicd, and it's awesome.

Since I liked it so much I started working on a Ruby library to
interface with the daemon and a bundled fancy CLI.


There is already (with newer version of connman) a nice CLI client named 
connmanctl.

You  might want to check it.
However, as far as I know, there is no ruby library to access connman so 
that could interest

some people to get one.


Came over on the IRC channel yesterday but everyone was idling (or
quite possibly in another timezone) so I thought I'd ask through a
more asynchronous mean.


Most of us are usually present during the week-days, EU times.


In the CLI I'm making I wanted to list the wifi services with the
access point BSSID and the channel, but after digging through the API
documentation and looking at some GUIs that didn't have that feature I
came to realize there's no way to have access to that information.

Is there a way to get access to that? Maybe I just overlooked
something while digging through the documentation, but in the service
properties dict there's no such data, so I guess it's not there.

If there is no way is there a reason for its absence, and if there's
no reason, are patches welcome?


ConnMan hides whatever information which is never required for the 
end-user and for the UI
itself. No-one needs the BSSID or the channel, seriously. This is up to 
the wifi daemon and/or
the network management daemon (connman here) to handle such information 
relevantly.


About BSSID, if you have 2+ AP sharing the same network (same SSID, same 
security,
different channels) ConnMan will still show 1 network (and not 2+ BSSID 
entries).
The user should not care what AP to select precisely: ConnMan and - in 
this case -

Wpa_supplicant will ensure he gets connected to the best AP among those
(strongest signal, lowest noise, so it will pick up the proper AP/Channel).

The name of a wifi service is the wifi network's SSID. That's all what 
needed to connect to it.
Depending on its security settings, connman will ask the credentials 
through Agent API.
And for whatever low level stuff a user should never care about: connman 
will handle it

(wifi roaming, storing the settings, etc etc...).

Also, be aware that ConnMan sorts the services for you: by technology 
type, signal strength

(for wifi for instance) etc... so you should not have to care about that.

Br,

Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: [PATCH] doc: Add informations about the experimental P2P Peer services support

[Tomasz Bursztyka]

Hi Daniel,


Hi Tomasz,

On 07/04/2014 03:05 PM, Tomasz Bursztyka wrote:

As soon as p2p technology is present, whether it is enabled or not, it
will be possible to register and un-register P2P Peer services. These
will be served once p2p technology gets enabled.

When scanning for Peers is possible, Peer objects will show the proposed
services of those if some are present.
---
  doc/manager-api.txt | 31 +++
  doc/peer-api.txt|  5 +
  2 files changed, 36 insertions(+)

diff --git a/doc/manager-api.txt b/doc/manager-api.txt
index 05d2701..3034c1e 100644
--- a/doc/manager-api.txt
+++ b/doc/manager-api.txt
@@ -156,6 +156,37 @@ Methodsdict GetProperties()
   Possible Errors: [service].Error.InvalidArguments
  +void RegisterPeerService(array{byte} specification, boolean
master) [experimental]
+
+Registers a local P2P Peer service
+
+If p2p technology is not available, this will raise an
+error on such support.

I have troubles to parse this '... on such support'. Should that read
'not supported'?


I might rephrase this yes, will send another version




This behavior does not apply if
+such technology is just disabled.
+
+A Peer service belongs to the process that registers
+it, thus if that process dies, its Peer services will
+be destroyed as well.
+
+"specification" is the TLV formated byte array
+describing the P2P service.

Is there a special meaning behind the different writtings of p2p vs P2P?


p2p is for the connman's technology. P2P if for the concrete technology. 
Don't know
if it matters to make such differentiation actually. I could write all 
as 'p2p' directly.





+
+Connman will be able to determine in most cases

ConnMan


+whether to be the P2P Group Owner or not.

I am ignorant to p2p: Should'nt the rules when ConnMan is Group Owner or
not be documented?


You are right, ConnMan hides most of the p2p group but when proposing 
services
there are really particular case when ConnMan cannot decide on its own 
to be the GO or not,
for instance some vendor specific service that would strictly require to 
be the GO. Thus this

entry here, there is no other way. And thus the explanation below as well.





If the
+service must belong to a group that this device
+manages, the "master" property can be set. Do not set
+the "master" property unless you are absolutely sure
+you know what you are doing.
+
+Possible Errors: [service].Error.InvalidArguments
+ [service].Error.NotSupported
+
+void UnregisterPeerService(array{byte} specification)
[experimental]
+
+Unregisters an existing local P2P Peer service
+
+Possible Errors: [service].Error.InvalidArguments
+
  SignalsTechnologyAdded(object path, dict properties)
   Signal that is sent when a new technology is added.
diff --git a/doc/peer-api.txt b/doc/peer-api.txt
index e38066f..59a3351 100644
--- a/doc/peer-api.txt
+++ b/doc/peer-api.txt
@@ -57,3 +57,8 @@ Propertiesstring State [readonly] [experimental]
  string Netmask [readonly]
   The current configured IPv4 netmask.
+
+array{array{byte}} Services [readonly] [experimental]
+
+Array of P2P service specifications, which are
+themselves a TLV formated byte array.

I wonder if it would make sense to have a or two paragraph in
wifi-p2p-overview.txt explaining this interface. I am pretty sure some
guys will ask for examples :D


Sure, will do that when implementing this API.

Tomasz
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

RE: [PATCH] dnsproxy: Prefer results with domain name while domain_append is true

[Pasi Sjöholm]

>> --- a/src/dnsproxy.c
>> +++ b/src/dnsproxy.c
>> @@ -2068,7 +2068,8 @@ static int forward_dns_reply(unsigned char *reply, int 
>> reply_len, int protocol,
>>   }
>>
>>  out:
>> - if (hdr->rcode > 0 && req->numresp < req->numserv)
>> + if ((hdr->rcode > 0 || (hdr->rcode == 0 && hdr->ancount == 0 &&
>> + req->append_domain)) && req->numresp < req->numserv)
>>   return -EINVAL;
>>
>>   request_list = g_slist_remove(request_list, req);
>Looks good, couple of comments

I did the modifications requested, both the commit message and the patch itself 
should look more clear now. Revised patch has subject "[PATCH] dnsproxy: Prefer 
responses with ancount>0 if append_domain is true".

Br,
Pasi
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Re: [PATCH] doc: Add informations about the experimental P2P Peer services support

[Daniel Wagner]

Hi Tomasz,

On 07/04/2014 03:05 PM, Tomasz Bursztyka wrote:
> As soon as p2p technology is present, whether it is enabled or not, it
> will be possible to register and un-register P2P Peer services. These
> will be served once p2p technology gets enabled.
> 
> When scanning for Peers is possible, Peer objects will show the proposed
> services of those if some are present.
> ---
>  doc/manager-api.txt | 31 +++
>  doc/peer-api.txt|  5 +
>  2 files changed, 36 insertions(+)
> 
> diff --git a/doc/manager-api.txt b/doc/manager-api.txt
> index 05d2701..3034c1e 100644
> --- a/doc/manager-api.txt
> +++ b/doc/manager-api.txt
> @@ -156,6 +156,37 @@ Methodsdict GetProperties()
>   Possible Errors: [service].Error.InvalidArguments
>  +void RegisterPeerService(array{byte} specification, boolean
> master) [experimental]
> +
> +Registers a local P2P Peer service
> +
> +If p2p technology is not available, this will raise an
> +error on such support.

I have troubles to parse this '... on such support'. Should that read
'not supported'?

>   This behavior does not apply if
> +such technology is just disabled.
> +
> +A Peer service belongs to the process that registers
> +it, thus if that process dies, its Peer services will
> +be destroyed as well.
> +
> +"specification" is the TLV formated byte array
> +describing the P2P service.

Is there a special meaning behind the different writtings of p2p vs P2P?

> +
> +Connman will be able to determine in most cases

ConnMan

> +whether to be the P2P Group Owner or not.

I am ignorant to p2p: Should'nt the rules when ConnMan is Group Owner or
not be documented?


>   If the
> +service must belong to a group that this device
> +manages, the "master" property can be set. Do not set
> +the "master" property unless you are absolutely sure
> +you know what you are doing.
> +
> +Possible Errors: [service].Error.InvalidArguments
> + [service].Error.NotSupported
> +
> +void UnregisterPeerService(array{byte} specification)
> [experimental]
> +
> +Unregisters an existing local P2P Peer service
> +
> +Possible Errors: [service].Error.InvalidArguments
> +
>  SignalsTechnologyAdded(object path, dict properties)
>   Signal that is sent when a new technology is added.
> diff --git a/doc/peer-api.txt b/doc/peer-api.txt
> index e38066f..59a3351 100644
> --- a/doc/peer-api.txt
> +++ b/doc/peer-api.txt
> @@ -57,3 +57,8 @@ Propertiesstring State [readonly] [experimental]
>  string Netmask [readonly]
>   The current configured IPv4 netmask.
> +
> +array{array{byte}} Services [readonly] [experimental]
> +
> +Array of P2P service specifications, which are
> +themselves a TLV formated byte array.

I wonder if it would make sense to have a or two paragraph in
wifi-p2p-overview.txt explaining this interface. I am pretty sure some
guys will ask for examples :D

cheers,
daniel

___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman