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: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan (Jose Blanquicet)
2. Re: [PATCH] technology: Deny P2P finding if technology is
disabled (Patrik Flykt)
3. Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan (Patrik Flykt)
4. Re: intermittent failures (Patrik Flykt)
5. Re: Prevent scanning on tethering interface (Patrik Flykt)
6. Re: [PATCH] technology: Deny P2P finding if technology is
disabled (Jose Blanquicet)
7. [PATCH] gsupplicant: Add DBGs to trace errors from
wpa_supplicant ([email protected])
8. [PATCH v2] technology: Deny P2P finding if technology is
disabled ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Mar 2017 10:24:10 +0000
From: Jose Blanquicet <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: Patrik Flykt <[email protected]>, [email protected],
[email protected]
Subject: Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan
Message-ID:
<CAFC8iJ+c703pOtCqdH6Hm9hbR5Yi=b_dpaacytkjw0t39a7...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
On Mon, Mar 13, 2017 at 9:16 AM, Daniel Wagner wrote:
>> In addition, as you know, that -5 in your log is the mapping ConnMan
>> does to wpa_s errors, I think ConnMan should at least print the actual
>> wpa_s error in order to find it into the logs later for the analysis.
>> For instance, that would be very useful in cases like this, do you
>> agree?
>>
>> diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
>> index 36c4dd5..0862e45 100644
>> --- a/gsupplicant/supplicant.c
>> +++ b/gsupplicant/supplicant.c
>> @@ -4987,7 +4987,9 @@ static void interface_disconnect_result(const char
>> *error,
>> SUPPLICANT_DBG("");
>>
>> if (error) {
>> + SUPPLICANT_DBG("error %s");
>> result = -EIO;
>> +
>> if (g_strcmp0("org.freedesktop.DBus.Error.UnknownMethod",
>> error) == 0)
>> result = -ECONNABORTED;
>>
>
> Any news on this one?
Sorry, I think all of you noticed the mistake, it was a quick/draft
idea I shared but I did not even compiled it. If you agree to add this
comment I will send a proper patch.
Regards,
Jose Blanquicet
------------------------------
Message: 2
Date: Mon, 13 Mar 2017 12:59:57 +0200
From: Patrik Flykt <[email protected]>
To: Jose Blanquicet <[email protected]>, Daniel Wagner
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] technology: Deny P2P finding if technology is
disabled
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2017-03-13 at 10:14 +0000, Jose Blanquicet wrote:
> BTW, From what I understood Patrick was testing this patch together
> with "Avoid to keep service in list if AP is not found during scan"
> patch set. Does he have comments?
I tested them together, but have no further comments.
The patch set "Avoid to keep service in list..." works better once
connected, but wpa_supplicant now has trouble connecting to anything
after waking up from sleep.
Cheers,
Patrik
------------------------------
Message: 3
Date: Mon, 13 Mar 2017 13:01:45 +0200
From: Patrik Flykt <[email protected]>
To: Jose Blanquicet <[email protected]>, Daniel Wagner
<[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH 0/5] Avoid to keep service in list if AP is not
found during scan
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Mon, 2017-03-13 at 10:24 +0000, Jose Blanquicet wrote:
> Sorry, I think all of you noticed the mistake, it was a quick/draft
> idea I shared but I did not even compiled it. If you agree to add
> this
> comment I will send a proper patch.
Yes, do send an update so we can trace down what connman/wpa_supplicant
think of the error condition.
Cheers,
Patrik
------------------------------
Message: 4
Date: Mon, 13 Mar 2017 13:03:11 +0200
From: Patrik Flykt <[email protected]>
To: Fred Ollinger <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: intermittent failures
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2017-03-10 at 01:01 +0000, Fred Ollinger wrote:
> I'm running connman 1.25 and I'm connecting by using the DBUS
> interface. This is built with Yocto.
>
> Is there any other information you need?
>
> Has this been fixed in a later release?
Please try latest, 1.25 is old and not supported since there are newer
versions available that fix a ton of issues.
Cheers,
Patrik
------------------------------
Message: 5
Date: Mon, 13 Mar 2017 13:05:22 +0200
From: Patrik Flykt <[email protected]>
To: Daniel Wagner <[email protected]>, Jose Blanquicet
<[email protected]>, [email protected], Tomasz Bursztyka
<[email protected]>
Subject: Re: Prevent scanning on tethering interface
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Sun, 2017-03-12 at 20:53 +0100, Daniel Wagner wrote:
> Hi Jose,
>
> I added Tomasz to CC list. He might have some input on this topic.
>
> Thanks,
> Daniel
>
> On 03/09/2017 01:55 PM, Jose Blanquicet wrote:
> > Hi,
> >
> > The first issue takes place when user asks for a Scan on P2P
> > technology
> > and Tethering is enabled for WiFi technology, ConnMan will reply
> > with a
> > success to the request even if the P2P find does not actually
> > started.
> > The second issue occurs when user asks for a Scan on WiFi
> > technology and
> > WiFi tethering is enabled, in such case, ConnMan will never emit
> > the
> > reply and client (e.g. connmanctl) will go in D-Bus time-out.
> >
> > I investigated first case and I saw that ConnMan's scan algorithm
> > replies "success" to the request because ConnMan successfully makes
> > the
> > D-Bus call P2PDevice.Find() to ask wpa_supplicant to launch the P2P
> > find
> > even if wpa_supplicant will reply ?ScanError?.
> >
> > I suggest to check tethering state before calling P2PDevice.Find()
> > as is
> > done for Scan() to solve first issue and return -EBUSY instead of
> > zero
> > ("success") if tethering is enabled to solve the second issue, see
> > an
> > initial idea bellow. Doing so, ConnMan will save one useless D-Bus
> > call
> > toward wpa_s and will be able to correctly reply "Error" to the
> > scan
> > requests while tethering. We tested this in our systems and it
> > seems to
> > work but I was wondering if this solution could have problem in
> > systems
> > with other characteristics of WiFi interfaces/capabilities. What do
> > people think?
> >
> > diff --git a/plugins/wifi.c b/plugins/wifi.c
> > index f8d88fa..a49031c 100644
> > --- a/plugins/wifi.c
> > +++ b/plugins/wifi.c
> > @@ -1802,14 +1802,14 @@ static int wifi_scan(enum
> > connman_service_type type,
> > ????????if (wifi->p2p_device)
> > ????????????????return 0;
> >
> > +???????if (wifi->tethering)
> > +???????????????return -EBUSY;
> > +
Yes, looks like the right thing to do here.
Cheers,
Patrik
> > ????????if (type == CONNMAN_SERVICE_TYPE_P2P)
> > ????????????????return p2p_find(device);
> >
> > ????????DBG("device %p wifi %p hidden ssid %s", device, wifi-
> > >interface,
> > ssid);
> >
> > -???????if (wifi->tethering)
> > -???????????????return 0;
> > -
> > ????????scanning = connman_device_get_scanning(device);
> >
> > ????????if (!ssid || ssid_len == 0 || ssid_len > 32) {
> >
> >
> > Regards,
> >
> > Jose Blanquicet
> >
> >
> > _______________________________________________
> > connman mailing list
> > [email protected]
> > https://lists.01.org/mailman/listinfo/connman
> >
>
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
------------------------------
Message: 6
Date: Mon, 13 Mar 2017 13:38:51 +0000
From: Jose Blanquicet <[email protected]>
To: Patrik Flykt <[email protected]>
Cc: Daniel Wagner <[email protected]>, [email protected]
Subject: Re: [PATCH] technology: Deny P2P finding if technology is
disabled
Message-ID:
<cafc8ijkfhd-amxypx99hy2jw-n7kbjqs8xqekvem3h8oyeu...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Patrik,
On Mon, Mar 13, 2017 at 10:59 AM, Patrik Flykt
<[email protected]> wrote:
> The patch set "Avoid to keep service in list..." works better once
> connected, but wpa_supplicant now has trouble connecting to anything
> after waking up from sleep.
So, if I understood well this is a regression the patch set is
introducing. I will send the patch to trace wpa_supplicant errors,
could you please find time to apply it and share with me the log of
this issue after waking up from sleep. I have not been able to
reproduce such issue as I said in the patch set thread, when my system
wakes up from sleep it correctly performs the reconnection.
Regards,
Jose Blanquicet
------------------------------
Message: 7
Date: Mon, 13 Mar 2017 13:40:59 +0000
From: [email protected]
To: [email protected]
Subject: [PATCH] gsupplicant: Add DBGs to trace errors from
wpa_supplicant
Message-ID:
<1489412459-23357-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
Errors comming from wpa_supplicant are mapped into standard errors. This patch
adds some DBGs to log those errors and ease debug in case one of these D-Bus
calls fails.
---
gsupplicant/supplicant.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index fcf5371..50e4aa6 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -3904,6 +3904,7 @@ static void interface_remove_result(const char *error,
if (error) {
err = -EIO;
+ SUPPLICANT_DBG("error: %s", error);
goto done;
}
@@ -4946,6 +4947,8 @@ static void network_remove_result(const char *error,
if (error) {
result = -EIO;
+ SUPPLICANT_DBG("error: %s", error);
+
if (g_strcmp0("org.freedesktop.DBus.Error.UnknownMethod",
error) == 0)
result = -ECONNABORTED;
@@ -5013,6 +5016,8 @@ static void interface_disconnect_result(const char *error,
if (error) {
result = -EIO;
+ SUPPLICANT_DBG("error: %s", error);
+
if (g_strcmp0("org.freedesktop.DBus.Error.UnknownMethod",
error) == 0)
result = -ECONNABORTED;
@@ -5182,8 +5187,10 @@ static void interface_p2p_connect_result(const char
*error,
SUPPLICANT_DBG("");
- if (error)
+ if (error) {
+ SUPPLICANT_DBG("error: %s", error);
err = parse_supplicant_error(iter);
+ }
if (data->callback)
data->callback(err, data->interface, data->user_data);
--
1.9.1
------------------------------
Message: 8
Date: Mon, 13 Mar 2017 13:42:35 +0000
From: [email protected]
To: [email protected]
Cc: [email protected], Jose Blanquicet
<[email protected]>
Subject: [PATCH v2] technology: Deny P2P finding if technology is
disabled
Message-ID:
<1489412555-23411-1-git-send-email-jose.blanquicet-melen...@magnetimarelli.com>
From: Jose Blanquicet <[email protected]>
This check is added because P2P and WiFi scan end up at the same device and at
that level there is not differentiation between WiFi and P2P, they both are WiFi
devices. Therefore, when device's power is checked in device.c:device_scan(),
it is actually checking only if WiFi technology is enabled thus P2P scan will go
ahead even if P2P technology is not enabled.
---
src/technology.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/technology.c b/src/technology.c
index 4574f1e..d2f0ae2 100644
--- a/src/technology.c
+++ b/src/technology.c
@@ -1077,6 +1077,10 @@ static DBusMessage *scan(DBusConnection *conn,
DBusMessage *msg, void *data)
DBG("technology %p request from %s", technology,
dbus_message_get_sender(msg));
+ if (technology->type == CONNMAN_SERVICE_TYPE_P2P &&
+ !technology->enabled)
+ return __connman_error_permission_denied(msg);
+
dbus_message_ref(msg);
technology->scan_pending =
g_slist_prepend(technology->scan_pending, msg);
--
1.9.1
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 17, Issue 12
***************************************
