Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: Skipping wpa_supplicant interfaces by mistake (Patrik Flykt)
2. Re: Query about Connman Session (Patrik Flykt)
3. RE: Skipping wpa_supplicant interfaces by mistake
(Blanquicet-Melendez Jose (MM))
4. [PATCH] gsupplicant: Avoid skipping wpa_supplicant interfaces
(Jose Blanquicet)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Jul 2016 16:16:47 +0300
From: Patrik Flykt <[email protected]>
To: "Blanquicet-Melendez Jose (MM)"
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: Skipping wpa_supplicant interfaces by mistake
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-07-07 at 12:13 +0000, Blanquicet-Melendez Jose (MM) wrote:
> Hi,
>
> If the wpa_supplicant has been launched before ConnMan, when the
> Connman calls the GetAll method on the fi.w1.wpa_supplicant1, the
> properties are returned as an array where there is an entry named
> "Interfaces". This entry is an array itself with only the object path
> of the current available interfaces. The problem occurs when ConnMan
> goes across this array using the function interface_added(), because
> this function tries also to extract the interface properties next to
> object path which is wrong because properties are not appended in
> this message reply. So, by doing dbus_message_iter_next(iter), we are
> actually skipping one interface of the list and it will result in a
> future error because the skipped interface(s) were not stored and
> ConnMan will not be aware of them.
Ouch.
> This issue is due to the function interface_added() is also used when
> signal "fi.w1.wpa_supplicant1.InterfaceAdded" arrives, and in this
> message the properties are actually appended. It could be solved by
> distinguishing the caller of the function interface_added(). It means
> to know if function interface_added() was called after a GetAll call
> or a InterfaceAdded signal in order to avoid trying to extract
> properties if they are not actually appended in the message.
>
> I think it could be done by taking advantage from the unused
> user_data argument of function interface_added(). Do you agree or is
> there something we are missing?
Looks like that after looking at it quickly. Maybe use a bool and wrap
it with with GUINT_TO_POINTER or such?
Cheers,
Patrik
------------------------------
Message: 2
Date: Tue, 12 Jul 2016 16:40:57 +0300
From: Patrik Flykt <[email protected]>
To: Benjamin Ioller <[email protected]>,
[email protected]
Subject: Re: Query about Connman Session
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, 2016-06-30 at 15:05 +0200, Benjamin Ioller wrote:
> Hello,?
> ?
> I'm?using Connman (v-1.32) on my Raspberry Pi and I wanted to try the
> session mode.
> I found quite few interesting mailings and I looked over the code
> (session.c, test-session) and the doc, but it looks like session is
> not really?a nowadays topic.
> Does someone use the Connman's session? and?for which application?
> Can you give me an?example?
Ping wagi on IRC, he was the last known user.
> So here is?what I understood so far about the session mode:
> Connman session allows the application to use specific network
> setting as selected technologies, roaming policy...
> Connman uses Iptable to do so.?Connman creates rules in the mangle
> table?to mark the packet based on the UID/GID.
> Then rules are added to the filter table?depending on the allowed
> bearers, and other properties.
> This routing is only functional when the connman state option is ON.
If you mean Manager API?SessionMode boolean property, that one does
nothing. Sessions are nowadays always available and active as soon as
someone calls?CreateSession().
?
> Connman? proposes two ways to?create a?session :
> First, the application?creates it's own session using the method
> form?/net.connman.manager. I try to?use this method with a python
> script, the application creates a session, connects to it and sends
> UDP packet to a local host via ethernet. But I didn't manage to setup
> the AllowedBearers,?neither with
> manager.CreateSession({"AllowedBearers":Glib.Variant('s','ethernet')}
> ,notifier_path)
> nor
> Session.Change("AllowedBeares",Glib.Variant('s','ethernet')).
> I have Variant?encoding issue. Do you have any advice or exemple?
See the python code in test/test-session, it should work.
> I was also wondering how does the?mangle table?identify the
> application's packet? (or maybe it's just the UID again?)
The detection is done with UID or GID and set up in
'init_firewall_session()' using MARK target. The routing table is
identified with id numbers created on the fly, see 'session_mark' and
'init_routing_table(session)' in src/session.c.
> The second way is to use??session_policy. With this method you can
> mark packet only based on the UID or GID. I need to create UID.policy
> in?var/lib/connman/session_policy_local?which contained the different
> parameters.
With a policy plugin one can fine tune what parameters in
CreateSession() calls are allowed. No policy module, no constraints for
CreateSession() (IIRC, or that was the intention). The provided session
policy is just a simple example, one can create a new policy module
containing more code and get something fancy as a policy decision
instead of reading a simple file.
> But when I turn?the?Connman's state session On, nothing happened...
> My pi user is still able to use wifi even if the pi.policy have
> only?Ethernet as AllowedBearers.?I suspect?the issue?comes from user
> rights or something...
CreateSession() has to be called also so that the specific session
routing and iptables rules are enabled. Otherwise it is assumed that
the default routing table is followed.
> ?Does somebody had similar issue?
> By the way,?is the session priority?only for notification hierarchy
> or does?the session priority have some effect on the network traffic
> (during congestion?)?
I don't remember session priority having any special meaning.
> Hope these questions aren't too basic for you, and can help other.
> If you have any literature which could help, I'll take it!
If someone will provide documentation, we'll be glad to proofread it
:-)?
Cheers,
Patrik
------------------------------
Message: 3
Date: Tue, 12 Jul 2016 14:12:30 +0000
From: "Blanquicet-Melendez Jose (MM)"
<[email protected]>
To: Patrik Flykt <[email protected]>,
"[email protected]" <[email protected]>
Subject: RE: Skipping wpa_supplicant interfaces by mistake
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Patrik,
In fact, if you look at the extraction of the EapMethods, it is required to
handle an array of strings (The same procedure required to extract the
Interface's object paths). In EapMethods extraction, the function
supplicant_dbus_array_foreach goes across the array and funcion eap_method()
just gets the actual value. That's exactly what interface_added() should do if
it's called from service_property. Clearly, after that, it is required to
perform the GetAll over the just gotten Interface.
Regarding the question, yes, the idea would be to use
GUINT_TO_POINTER/GPOINTER_TO_UINT functions to get a value to distinguish the
caller and then perform the correct action. I will send the path.
Best regards,
Jose Blanquicet
> -----Original Message-----
> From: Patrik Flykt [mailto:[email protected]]
> Sent: Tuesday, July 12, 2016 3:17 PM
> To: Blanquicet-Melendez Jose (MM); [email protected]
> Subject: Re: Skipping wpa_supplicant interfaces by mistake
>
> On Thu, 2016-07-07 at 12:13 +0000, Blanquicet-Melendez Jose (MM) wrote:
> > Hi,
> >
> > If the wpa_supplicant has been launched before ConnMan, when the
> > Connman calls the GetAll method on the fi.w1.wpa_supplicant1, the
> > properties are returned as an array where there is an entry named
> > "Interfaces". This entry is an array itself with only the object path
> > of the current available interfaces. The problem occurs when ConnMan
> > goes across this array using the function interface_added(), because
> > this function tries also to extract the interface properties next to
> > object path which is wrong because properties are not appended in this
> > message reply. So, by doing dbus_message_iter_next(iter), we are
> > actually skipping one interface of the list and it will result in a
> > future error because the skipped interface(s) were not stored and
> > ConnMan will not be aware of them.
>
> Ouch.
>
> > This issue is due to the function interface_added() is also used when
> > signal "fi.w1.wpa_supplicant1.InterfaceAdded" arrives, and in this
> > message the properties are actually appended. It could be solved by
> > distinguishing the caller of the function interface_added(). It means
> > to know if function interface_added() was called after a GetAll call
> > or a InterfaceAdded signal in order to avoid trying to extract
> > properties if they are not actually appended in the message.
> >
> > I think it could be done by taking advantage from the unused user_data
> > argument of function interface_added(). Do you agree or is there
> > something we are missing?
>
> Looks like that after looking at it quickly. Maybe use a bool and wrap it with
> with GUINT_TO_POINTER or such?
>
> Cheers,
>
> Patrik
________________________________
VISITA IL NOSTRO NUOVO SITO WEB! - VISIT OUR NEW WEB SITE!
www.magnetimarelli.com
Confidential Notice: This message - including its attachments - may contain
proprietary, confidential and/or legally protected information and is intended
solely for the use of the designated addressee(s) above. If you are not the
intended recipient be aware that any downloading, copying, disclosure,
distribution or use of the contents of the above information is strictly
prohibited.
If you have received this communication by mistake, please forward the message
back to the sender at the email address above, delete the message from all
mailboxes and any other electronic storage medium and destroy all copies.
Disclaimer Notice: Internet communications cannot be guaranteed to be safe or
error-free. Therefore we do not assure that this message is complete or
accurate and we do not accept liability for any errors or omissions in the
contents of this message.
------------------------------
Message: 4
Date: Tue, 12 Jul 2016 18:06:52 +0200
From: Jose Blanquicet <[email protected]>
To: [email protected]
Subject: [PATCH] gsupplicant: Avoid skipping wpa_supplicant interfaces
Message-ID: <[email protected]>
If the wpa_supplicant has been launched before ConnMan, when the Connman
calls the GetAll method on fi.w1.wpa_supplicant1, the properties are
returned as an array where there is an entry named "Interfaces". This
entry is an array itself with only the object path of the current
available interfaces. The problem occurs when ConnMan goes across this
array using the function interface_added(), because this function tries
also to extract the interface properties next to object path which is
wrong because properties are not appended in this message reply. So, by
doing dbus_message_iter_next(iter), we are actually skipping one interface
of the list and it will result in a future error because the skipped
interface(s) were not stored and ConnMan will not be aware of them.
This issue is due to the function interface_added() is also used when
signal "fi.w1.wpa_supplicant1.InterfaceAdded" arrives, and in this
message the properties are actually appended. This patch aims to solve
this issue by distinguishing the caller to avoid trying to extract
properties if they are not appended in the message.
---
gsupplicant/supplicant.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 09a3ac5..5a038d1 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -2320,6 +2320,7 @@ static void interface_added(DBusMessageIter *iter, void
*user_data)
{
GSupplicantInterface *interface;
const char *path = NULL;
+ unsigned int properties_appended = GPOINTER_TO_UINT(user_data);
SUPPLICANT_DBG("");
@@ -2338,18 +2339,20 @@ static void interface_added(DBusMessageIter *iter, void
*user_data)
if (!interface)
return;
+ if (properties_appended == 0) {
+ supplicant_dbus_property_get_all(path,
+ SUPPLICANT_INTERFACE
".Interface",
+ interface_property, interface,
+ interface);
+ return;
+ }
+
dbus_message_iter_next(iter);
if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_INVALID) {
supplicant_dbus_property_foreach(iter, interface_property,
interface);
interface_property(NULL, NULL, interface);
- return;
}
-
- supplicant_dbus_property_get_all(path,
- SUPPLICANT_INTERFACE ".Interface",
- interface_property, interface,
- interface);
}
static void interface_removed(DBusMessageIter *iter, void *user_data)
@@ -2409,7 +2412,8 @@ static void service_property(const char *key,
DBusMessageIter *iter,
dbus_message_iter_get_basic(iter, &debug_showkeys);
SUPPLICANT_DBG("Debug show keys %u", debug_showkeys);
} else if (g_strcmp0(key, "Interfaces") == 0) {
- supplicant_dbus_array_foreach(iter, interface_added, NULL);
+ supplicant_dbus_array_foreach(iter, interface_added,
+ GUINT_TO_POINTER((unsigned int)
false));
} else if (g_strcmp0(key, "EapMethods") == 0) {
supplicant_dbus_array_foreach(iter, eap_method, NULL);
debug_strvalmap("EAP method", eap_method_map, eap_methods);
@@ -2479,7 +2483,7 @@ static void signal_interface_added(const char *path,
DBusMessageIter *iter)
SUPPLICANT_DBG("path %s %s", path, SUPPLICANT_PATH);
if (g_strcmp0(path, SUPPLICANT_PATH) == 0)
- interface_added(iter, NULL);
+ interface_added(iter, GUINT_TO_POINTER((unsigned int) true));
}
static void signal_interface_removed(const char *path, DBusMessageIter *iter)
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 9, Issue 4
*************************************
