Re: [PATCH 2/3] client: Fix index for IPv6 configuration option

2013-05-23 Thread Kok, Auke-jan H
On Wed, May 22, 2013 at 2:21 AM, Patrik Flykt
patrik.fl...@linux.intel.com wrote:
 ---
  client/commands.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/client/commands.c b/client/commands.c
 index 263453a..8c67ebc 100644
 --- a/client/commands.c
 +++ b/client/commands.c
 @@ -737,7 +737,7 @@ static void config_append_ipv6(DBusMessageIter *iter, 
 void *user_data)
 if (opts[1] != NULL) {
 append-values = 2;

 -   if (g_strcmp0(opts[0], prefered) != 0) {
 +   if (g_strcmp0(opts[1], prefered) != 0) {

I believe the spelling is preferred. Hence:

http://en.wiktionary.org/wiki/prefered
http://dictionary.reference.com/browse/prefered

Both state that this spelling is incorrect.

Cheers,

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


Re: [PATCH 2/3] systemd: Use environment file for connmand debug options

2013-03-15 Thread Kok, Auke-jan H
On Thu, Mar 14, 2013 at 12:22 PM, Jukka Rissanen
jukka.rissa...@gmail.com wrote:
 Hi Marcel,

 On 14 March 2013 19:18, Marcel Holtmann mar...@holtmann.org wrote:
 In general we want to be able to enable/disable debug messages at runtime. 
 That is where I want this to go. Same as the kernel allows to 
 enable/disable dynamic debug at runtime.

 Sure, why not. My patch does not contradict with this goal.

 I like to have one way and one way only. And actually connmanctl debug 
 pattern sounds like a pretty good way of giving this to a user.


 Hmm, do you mean that the user would not be able to activate debugging
 via -d option any longer?

I don't see a reason to remove the cmdline option, it does serve a
purpose to enable debugging right from the start. Or even just running
it in the foreground in a terminal.

But from a user/developer point of view, we should not ship a service
file that jumps through hoops to enable/disable debugging - that is
something a developer locally should do and they should know how to.

Having the `connmanctl debug bool` option will allow you to pass
instructions like this:

- disconnect your service
- run `journalctl /usr/sbin/connmand` in a terminal to start capturing
debug output
- type `connmanctl debug on`
- connect your service

That seems really easy and friendly to me.

There's also an alternative to modifying the connman.service file.
With systemd v198 you can now do:

mkdir -p /etc/systemd/system/connmand.service.d
echo -e [Service]\nExecStart=/usr/sbin/connmand -n -d\n 
/etc/systemd/system/connmand.service.d/debug.conf
... daemon-reload
... restart

I didn't test this myself though. And it still looks a bit like a kludge.

Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH 2/3] systemd: Use environment file for connmand debug options

2013-03-13 Thread Kok, Auke-jan H
On Wed, Mar 13, 2013 at 9:36 AM, Marcel Holtmann mar...@holtmann.org wrote:
 src/connman.service.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/src/connman.service.in b/src/connman.service.in
 index 2e9e4d5..fa57d4e 100644
 --- a/src/connman.service.in
 +++ b/src/connman.service.in
 @@ -6,7 +6,8 @@ After=syslog.target
 Type=dbus
 BusName=net.connman
 Restart=on-failure
 -ExecStart=@prefix@/sbin/connmand -n
 +EnvironmentFile=-@sysconfdir@/connman/connmand.env
 +ExecStart=@prefix@/sbin/connmand -n $DEBUG
 StandardOutput=null

 if we want to do that, then using a directory or blob file support is better.

 I still question why this is a better approach then manually adding the 
 service file. Since you still need to restart the daemon.

 In general we want to be able to enable/disable debug messages at runtime. 
 That is where I want this to go. Same as the kernel allows to enable/disable 
 dynamic debug at runtime.

Something like `connmanctl debug [bool]` ?

Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: Pre-configuring an ethernet interface

2013-01-09 Thread Kok, Auke-jan H
On Wed, Jan 9, 2013 at 4:32 PM, Felipe Ferreri Tonello
e...@felipetonello.com wrote:
 On 01/09/2013 11:17 AM, Justin Maggard wrote:

 I have a system with multiple ethernet interfaces, and I'm a bit confused
 as to how connman is expected to work with this.  How can I get connman to
 give me a list of all interfaces, both with and without a carrier?  The


 You need to use the dbus interfaces to do that.

 Try to use the scripts that comes with connman.

 to enable ethernet:
 test-connman enable ethernet

 lists all the services:
 test-connman services

Most of this should work with the cli - connmanctl - which is part of
the connman project source tree (you may have to convince the
configure scripts to install it). You can statically configure
interfaces and enable/disable them, setup dhcp, view link status etc.


Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: cli or gui client

2012-12-13 Thread Kok, Auke-jan H
On Thu, Dec 13, 2012 at 12:14 AM, Patrik Flykt
patrik.fl...@linux.intel.com wrote:
 On Wed, 2012-12-12 at 10:43 -0800, Kok, Auke-jan H wrote:
 connman creates a folder for each network under /var/lib/connman.

 You should be able to pre-define a network in there and use connmanctl
 to connect to a service. This way you can set WPA/WEP passwords
 without any client. However, the format of these files isn't
 documented AFAIK.

 No. You should not touch/create any directories in /var/lib/connman. The
 only thing one is allowed to add/remove in /var/lib/connman are the wifi
 provisioning files ending with '.config' and documented in
 doc/config-format.txt. ConnMan will pick up the provisioned wifi network
 from the .config files and use those settings when a matching SSID is
 found. After that connmanctl can be used to connect/disconnect the
 service normally.

ahhh, thanks for the pointer - I never saw this file before.

Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: cli or gui client

2012-12-12 Thread Kok, Auke-jan H
On Tue, Dec 11, 2012 at 9:41 AM, Carsten Mattner
carstenmatt...@gmail.com wrote:
 On Tue, Dec 11, 2012 at 2:21 AM, Zheng, Jeff jeff.zh...@intel.com wrote:
  How would I connect to wireless ap with SSID ap1 and PSK psk1?
  connmanctl connect wifi 

 connmanctl does not yet support Agent functionality, so you can't use it to
 provide passwords for WPA/WEP connected networks. You can connect to any
 wifi network with it, but authentication will fail.


 Yes. It's bug https://bugs.meego.com/show_bug.cgi?id=25885.

 You can use connman test python script instead:
 1. In one console, run simple-agent Name=AP ssid Passphrase=key
 2. In another console, run test-connman connect AP service path

 Thanks for the bug link.

 How can I debug what's preventing the test script to work at all?
 It's a default installation of connman on archlinx with the dbus
 policy I had linked to. Once I have that figured out I can try the
 various clients.

 Is there really no well defined place to store connection profiles
 one can refer to with connmanctl?

connman creates a folder for each network under /var/lib/connman.

You should be able to pre-define a network in there and use connmanctl
to connect to a service. This way you can set WPA/WEP passwords
without any client. However, the format of these files isn't documented AFAIK.

Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: cli or gui client

2012-12-10 Thread Kok, Auke-jan H
On Mon, Dec 10, 2012 at 6:46 AM, Carsten Mattner
carstenmatt...@gmail.com wrote:
 On Mon, Dec 10, 2012 at 3:32 PM, Patrik Flykt
 patrik.fl...@linux.intel.com wrote:
 On Mon, 2012-12-10 at 11:25 +0100, Carsten Mattner wrote:
 2) what (cli) clients can I use?

 There is a client/connmanctl in the source code, I don't know if it
 enabled or installed by Archlinux. There also exists a ConnMan extension
 for GNOME3 on extensions.gnome.org.

 Yes it's included in that package. I tried that command but seemed
 to still have the error connecting to connmand even though my
 users was in the 'network' group. Is the following configuration
 enough to give access?
 https://projects.archlinux.org/svntogit/community.git/tree/trunk/allow_group_network.diff?h=packages/connman

 https://projects.archlinux.org/svntogit/community.git/tree/trunk?h=packages/connman

 Do I have to pre-configure connections in /etc or ~/.config before
 I can refer to them with connmanctl? Any sample files I can base
 known connections on you can refer me to?

 How would I connect to wireless ap with SSID ap1 and PSK psk1?
 connmanctl connect wifi 

connmanctl does not yet support Agent functionality, so you can't use
it to provide passwords for WPA/WEP connected networks. You can
connect to any wifi network with it, but authentication will fail.

Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH] client: Fix AutoConnect configuration

2012-09-20 Thread Kok, Auke-jan H
On Thu, Sep 20, 2012 at 4:12 PM, Justin Maggard jmaggar...@gmail.com wrote:
 Changing the AutoConnect setting via connmanctl does not work, due to the
 mistaken use of || instead of .
 This patch fixes the issue, and tries to make things a little more readable.
 ---
  client/commands.c |   20 
  1 file changed, 12 insertions(+), 8 deletions(-)

 diff --git a/client/commands.c b/client/commands.c
 index 0caacd9..22d5b3c 100644
 --- a/client/commands.c
 +++ b/client/commands.c
 @@ -134,16 +134,20 @@ int config_switch(int argc, char *argv[], int c, 
 DBusConnection *conn)

 switch (c) {
 case 'a':
 -   if (*optarg != 'y' || *optarg != 'n' || *optarg != '1' ||
 -   *optarg != '0' || *optarg != 't' ||
 -   *optarg != 'f')
 -   return -EINVAL;
 -   if (*optarg == 'y' || *optarg == '1' ||
 -   *optarg == 't')
 +   switch (*optarg) {
 +   case 'y':
 +   case '1':
 +   case 't':
 val = TRUE;
 -   else if (*optarg == 'n' || *optarg == '0' ||
 -   *optarg == 'f')
 +   break;
 +   case 'n':
 +   case '0':
 +   case 'f':
 val = FALSE;
 +   break;
 +   default:
 +   return -EINVAL;
 +   }
 error = set_service_property(conn, message, argv[1],
 AutoConnect, NULL,
 val, 0);
 --
 1.7.9.5

Thanks, that indeed looks a lot better.


Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH 00/12] New CLI v3

2012-08-29 Thread Kok, Auke-jan H
On Wednesday, August 29, 2012, Marcel Holtmann mar...@holtmann.org wrote:
 Hi Tudor,

 This patch set introduces a new CLI for Connman to use with the current
tree.
 The new files in the client directory compile under a single executable
 called cmn, which provides a larger range of functions. It consists of
 patches that add the new client and documentation, remove the old client,
 and update the Makefile.am and other associated files.

 I do not really like the name cmn. I can not even make out what it is
 suppose to be standing for.

 So either just short cm as it is right now or connmanctl to follow in
 line with what we have with systemctl, journalctl etc.

Agreed. I'm partial to connmanctl myself...

Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman


Re: [PATCH 0/7] Introduction to new CLI

2012-08-01 Thread Kok, Auke-jan H
On Wed, Aug 1, 2012 at 3:50 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
 On Wed, Aug 1, 2012 at 7:20 PM, Marcel Holtmann mar...@holtmann.org wrote:
 Hi Gustavo,

 nice, but I wonder why it's cmn... since it's a new maybe we could
 call it connmanctl or something like that? At least it's in line with
 systemd and apache, both have their ctl variants.

 I would prefer to just call it cm. Short is beautiful.

 partially agreed... but  the problem it's just meaningful if you use
 it daily. If you rarely use it and for some reason your GUI is broken,
 you need to connect... how to remember the connman client is cm?
 Likely you'll try connmanTAB and see what comes out. Then
 connmanctl is easy to find.

 Also, in that scenario it's also useful to have an agent in this tool,
 if there is no other agent running. It's required if you're connecting
 to a password protected wifi.

an agent is part of the plan - but we decided to go through external
review first before focusing on new features.

Auke
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman