11:40 p.m.
Hi,
I have implemented GUI for connman which in particular connects to 802.1x
services.
Since for them we have to use provision file I have following simple
algorithm.
1. Write connection parameters in provision file and flush it.
2. Call connman service Connect method via D-Bus.
But it looks like sometimes I have Connect handled sooner than provision
file reloaded.
I am not 100% sure, but looking at the source code I think that this
situation is at least theoretically possible. Isn't it?
Kind regards,
Vasyl
11:05 a.m.
Hi Vasyl,
On 11/06/2017 11:40 PM, Vasyl Vavrychuk wrote:
I have implemented GUI for connman which in particular connects to
802.1x services.
Since for them we have to use provision file I have following simple
algorithm.
1. Write connection parameters in provision file and flush it.
2. Call connman service Connect method via D-Bus.
But it looks like sometimes I have Connect handled sooner than provision
file reloaded.
I am not 100% sure, but looking at the source code I think that this
situation is at least theoretically possible. Isn't it?
I think this race is real. ConnMan uses inotify to monitor changes in
the /var/lib/connman directory. Whenever a file is updated it will take
some time until ConnMan sees the changes. ConnMan itself is single
threaded and therefore all changes have been processed or they haven't.
Anyway not really sure how to fix this. They only way I see is to add a
D-Bus call which writes the provisioning to the disc. Though this idea
has not been popular around here. I personally don't mind having such an
extension.
Thanks,
Daniel
6:20 a.m.
Hi, Daniel,
I found an attempt to implement EAP parameters via D-Bus api
https://lists.01.org/pipermail/connman/2010-August/002420.html.
Could you merge proposed patch to resolve my issue or this patch should be
reworked according to some way suggested in mailing list?
Kind regards,
Vasyl
On Sun, Nov 12, 2017 at 12:05 PM, Daniel Wagner <wagi(a)monom.org> wrote:
Hi Vasyl,
On 11/06/2017 11:40 PM, Vasyl Vavrychuk wrote:
> I have implemented GUI for connman which in particular connects to 802.1x
> services.
>
> Since for them we have to use provision file I have following simple
> algorithm.
>
> 1. Write connection parameters in provision file and flush it.
> 2. Call connman service Connect method via D-Bus.
>
> But it looks like sometimes I have Connect handled sooner than provision
> file reloaded.
>
> I am not 100% sure, but looking at the source code I think that this
> situation is at least theoretically possible. Isn't it?
>
I think this race is real. ConnMan uses inotify to monitor changes in the
/var/lib/connman directory. Whenever a file is updated it will take some
time until ConnMan sees the changes. ConnMan itself is single threaded and
therefore all changes have been processed or they haven't.
Anyway not really sure how to fix this. They only way I see is to add a
D-Bus call which writes the provisioning to the disc. Though this idea has
not been popular around here. I personally don't mind having such an
extension.
Thanks,
Daniel
10:12 p.m.
Hi Vasyl,
On 12/06/2017 06:20 AM, Vasyl Vavrychuk wrote:
Hi, Daniel,
I found an attempt to implement EAP parameters via D-Bus api
https://lists.01.org/pipermail/connman/2010-August/002420.html.
Thanks for digging up this patch. I could remember there was a proposal
but didn't find it. Anyway, as Marcel suggest, it would be better to
have an upload config file D-Bus API instead of the proposed API.
Could you merge proposed patch to resolve my issue or this patch
should
be reworked according to some way suggested in mailing list?
I was trying to come up with an proposal for an API right now. But I
don't this would be a good idea to do this:
Manager:
void LoadProvisioning(object service, string provisioning)
Upload a provisioning for given service.
Some more pondering is needed :)
Thanks,
Daniel
11:07 p.m.
Hi, Daniel,
Thanks for feedback. Please find my comment below.
On Wed, Dec 6, 2017 at 11:12 PM, Daniel Wagner <wagi(a)monom.org> wrote:
Manager:
void LoadProvisioning(object service, string provisioning)
Upload a provisioning for given service.
I think that besides setting this parameters to connman, we should provide
possibility to get this parameter from connman. It is because user may want
to find out what is current settings.
How about just to have in service api property
string Provisioning.
which is in XML (or maybe JSON) format. This is very simple rework of what
Lucio implemented and looks like it suits requirements of Marcel.
Kind regards,
Vasyl
9:32 a.m.
Hi Vasyl,
On 12/06/2017 11:07 PM, Vasyl Vavrychuk wrote:
Hi, Daniel,
Thanks for feedback. Please find my comment below.
On Wed, Dec 6, 2017 at 11:12 PM, Daniel Wagner <wagi(a)monom.org
<mailto:wagi@monom.org>> wrote:
Manager:
void LoadProvisioning(object service, string provisioning)
Upload a provisioning for given service.
I think that besides setting this parameters to connman, we should
provide possibility to get this parameter from connman. It is because
user may want to find out what is current settings.
How about just to have in service api property
string Provisioning.
which is in XML (or maybe JSON) format. This is very simple rework of
what Lucio implemented and looks like it suits requirements of Marcel.
The main reason I was pondering why to add it to the Manager API is that
we might now have the service object there. So it's about the use case
when the user wants to add a provisioning for a service which is not yet
there, e.g. WiFi network is not yet in reach.
But then my API proposal has the same problem. We would need to know in
advanced the object path. And that is something we really don't want to
do. The path should be considered as random strings.
I think we have a problem with the different concepts here. Thinking
load: an entry in the provisioning file is identified either via MAC or
SSID, IINW. If we follow this we should reuse those keys for an entry.
Would that make sense?
Thanks,
Daniel
1:39 a.m.
Hi,
I want to develop demo of using Provisioning property in JSON format. For
this I need JSON parser but when I use JSON Glib I am getting conflicts
In file included from /usr/include/glib-2.0/gio/gio.h:26:0,
from
/usr/include/json-glib-1.0/json-glib/json-generator.h:32,
from /usr/include/json-glib-1.0/json-glib/json-glib.h:32,
from src/service.c:33:
/usr/include/glib-2.0/gio/giotypes.h:546:47: error: conflicting types for
‘GDBusProxy’
typedef struct _GDBusProxy GDBusProxy;
^~~~~~~~~~
In file included from src/service.c:30:0:
Does this means that I can not use JSON Glib?
Kind regards,
Vasyl
On Thu, Dec 7, 2017 at 12:07 AM, Vasyl Vavrychuk <vvavrychuk(a)gmail.com>
wrote:
Hi, Daniel,
Thanks for feedback. Please find my comment below.
On Wed, Dec 6, 2017 at 11:12 PM, Daniel Wagner <wagi(a)monom.org> wrote:
>
> Manager:
>
> void LoadProvisioning(object service, string provisioning)
> Upload a provisioning for given service.
>
I think that besides setting this parameters to connman, we should provide
possibility to get this parameter from connman. It is because user may want
to find out what is current settings.
How about just to have in service api property
string Provisioning.
which is in XML (or maybe JSON) format. This is very simple rework of what
Lucio implemented and looks like it suits requirements of Marcel.
Kind regards,
Vasyl
10:04 p.m.
Hi Vasyl,
On 12/12/2017 01:39 AM, Vasyl Vavrychuk wrote:
Hi,
I want to develop demo of using Provisioning property in JSON format.
For this I need JSON parser but when I use JSON Glib I am getting conflicts
In file included from /usr/include/glib-2.0/gio/gio.h:26:0,
from
/usr/include/json-glib-1.0/json-glib/json-generator.h:32,
from /usr/include/json-glib-1.0/json-glib/json-glib.h:32,
from src/service.c:33:
/usr/include/glib-2.0/gio/giotypes.h:546:47: error: conflicting types
for ‘GDBusProxy’
typedef struct _GDBusProxy GDBusProxy;
^~~~~~~~~~
In file included from src/service.c:30:0:
Does this means that I can not use JSON Glib?
Oh, I didn't realize that the glib JSON parser has a dependency to GIO
and as you found out will not work with ConnMan.
We didn't want to introduce the object model of the GNOME libraries.
That's why we never used those parts of the glib.
I fear you need to use an other JSON implementation.
Thanks,
Daniel
1132
days inactive
1174
days old
7 comments
2 participants
participants (2)
-
Daniel Wagner -
Vasyl Vavrychuk