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: Error "wifi: No carrier" only to connman (Daniel Wagner)
   2. Re: Error "wifi: No carrier" only to connman (Jun Nie)
   3. Re: Error "wifi: No carrier" only to connman (Daniel Wagner)
   4. Re: Error "wifi: No carrier" only to connman (Jun Nie)
   5. Re: Error "wifi: No carrier" only to connman (Daniel Wagner)
   6. [PATCH 0/2] implements periodic online check (Julien Massot)
   7. [PATCH 1/2] service: track g_timeout for wispr try (Julien Massot)


----------------------------------------------------------------------

Message: 1
Date: Wed, 6 Mar 2019 15:44:40 +0100
From: Daniel Wagner <[email protected]>
To: Jun Nie <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Error "wifi: No carrier" only to connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

>> Can you check what ConnMan thinks about the device status?
>>
> This is status from connman when iwlist still works well for wifi. It
> seems no power issue, right?
> root@mbed-linux-os-5224:~# connmanctl state

What says 'tonnmanctl technologies'?


------------------------------

Message: 2
Date: Wed, 6 Mar 2019 22:48:09 +0800
From: Jun Nie <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Error "wifi: No carrier" only to connman
Message-ID:
        <cabymucnlm+cjfkmjpmy07zyuhruy1gofqqjdiggiok2lpws...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Daniel Wagner <[email protected]> ?2019?3?6??? ??10:44???
>
> >> Can you check what ConnMan thinks about the device status?
> >>
> > This is status from connman when iwlist still works well for wifi. It
> > seems no power issue, right?
> > root@mbed-linux-os-5224:~# connmanctl state
>
> What says 'tonnmanctl technologies'?

root@mbed-linux-os-5224:~# connmanctl technologies
/net/connman/technology/ethernet
  Name = Wired
  Type = ethernet
  Powered = True
  Connected = False
  Tethering = False
/net/connman/technology/wifi
  Name = WiFi
  Type = wifi
  Powered = True
  Connected = False
  Tethering = False
root@mbed-linux-os-5224:~# connmanctl scan wifi
Error /net/connman/technology/wifi: No carrier

Thanks for your time!
Jun


------------------------------

Message: 3
Date: Wed, 6 Mar 2019 16:00:20 +0100
From: Daniel Wagner <[email protected]>
To: Jun Nie <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Error "wifi: No carrier" only to connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

>> What says 'tonnmanctl technologies'?
> 
> root@mbed-linux-os-5224:~# connmanctl technologies
> /net/connman/technology/ethernet
>   Name = Wired
>   Type = ethernet
>   Powered = True
>   Connected = False
>   Tethering = False
> /net/connman/technology/wifi
>   Name = WiFi
>   Type = wifi
>   Powered = True
>   Connected = False
>   Tethering = False
> root@mbed-linux-os-5224:~# connmanctl scan wifi
> Error /net/connman/technology/wifi: No carrier

Hmm, let's go one step further. Can you start wpa_supplicant with debug
output on and log the interaction between ConnMan an wpa_supplicant?

First stop ConnMan and wpa_supplicant and then start wpa_s

        wpa_supplicant -u -s -ddd

and then ConnMan. Hopefully I remembered the options correctly. Look at
the wpa_s output if you see the scan request and look for the response.

Thanks,
Daniel


------------------------------

Message: 4
Date: Wed, 6 Mar 2019 23:20:41 +0800
From: Jun Nie <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Error "wifi: No carrier" only to connman
Message-ID:
        <CABymUCPYO7cX-M8rdwxxogVMMa6EiuQtchXSUp=1dzzeuez...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

Daniel Wagner <[email protected]> ?2019?3?6??? ??11:00???
>
> >> What says 'tonnmanctl technologies'?
> >
> > root@mbed-linux-os-5224:~# connmanctl technologies
> > /net/connman/technology/ethernet
> >   Name = Wired
> >   Type = ethernet
> >   Powered = True
> >   Connected = False
> >   Tethering = False
> > /net/connman/technology/wifi
> >   Name = WiFi
> >   Type = wifi
> >   Powered = True
> >   Connected = False
> >   Tethering = False
> > root@mbed-linux-os-5224:~# connmanctl scan wifi
> > Error /net/connman/technology/wifi: No carrier
>
> Hmm, let's go one step further. Can you start wpa_supplicant with debug
> output on and log the interaction between ConnMan an wpa_supplicant?
>
> First stop ConnMan and wpa_supplicant and then start wpa_s
>
>         wpa_supplicant -u -s -ddd
>
> and then ConnMan. Hopefully I remembered the options correctly. Look at
> the wpa_s output if you see the scan request and look for the response.
>

I use this command as my version does not support -s.
wpa_supplicant -u -t -ddd 2>&1 > /tmp/wpa.log &

Thanks for the instruction! It seems a wpa_supplicant communication
issue. For the first scan operations on boot up, there is not scan
record in wpa_supplicant log. After disable/enable cycle, I still see
"No carrier" issue, but there is scan record in wpa_supplicant log
actually. And the following scan operations always success. Past
bY9K5DVj48 only contain log for  "No carrier" cases, but you can find
scan operation in the bottom. Is this a wpa_supplicant bug?
https://paste.ubuntu.com/p/bY9K5DVj48/

> Thanks,
> Daniel


------------------------------

Message: 5
Date: Wed, 6 Mar 2019 16:33:56 +0100
From: Daniel Wagner <[email protected]>
To: Jun Nie <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Error "wifi: No carrier" only to connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

> I use this command as my version does not support -s.
> wpa_supplicant -u -t -ddd 2>&1 > /tmp/wpa.log &
> 
> Thanks for the instruction! It seems a wpa_supplicant communication
> issue. For the first scan operations on boot up, there is not scan
> record in wpa_supplicant log. After disable/enable cycle, I still see
> "No carrier" issue, but there is scan record in wpa_supplicant log
> actually. And the following scan operations always success. Past
> bY9K5DVj48 only contain log for  "No carrier" cases, but you can find
> scan operation in the bottom. Is this a wpa_supplicant bug?
> https://paste.ubuntu.com/p/bY9K5DVj48/

That might be the case. I have to read up again how the whole scan API
is supposed to work. It is extremely tricky.

At least wpa_s is well known to be buggy, so the simplest thing is to
swap wpa_s with a newer or older version and see if you get a different
behavior.


------------------------------

Message: 6
Date: Wed,  6 Mar 2019 16:47:35 +0100
From: Julien Massot <[email protected]>
To: [email protected]
Subject: [PATCH 0/2] implements periodic online check
Message-ID: <[email protected]>

From: Julien Massot <[email protected]>

This patch set implements a periodic retry on online check.

That's something I have in my ConnMan tree for years, and may
have interrest to land mainline.

So if we fail our online check just after ready state, we will retry
periodically.

Once the online check succeed we stop probing the network.

That should be interresting for software which wait for internet connection
on boot.

I didn't test the ipv6 case so I will be happy if someone can give it a try.

Online checking is still not perfect since Internet connection may drop, after
a successful online check happen.

Daniel Mack: Since I changed a bit the logic of what you did before, I will be
happy to have your comment.


Julien Massot (2):
  service: track g_timeout for wispr try
  service: retry online check permanently until success

 src/service.c | 63 +++++++++++++++++++++++++++++++++++----------------
 1 file changed, 43 insertions(+), 20 deletions(-)

-- 
2.20.1



------------------------------

Message: 7
Date: Wed,  6 Mar 2019 16:47:36 +0100
From: Julien Massot <[email protected]>
To: [email protected]
Subject: [PATCH 1/2] service: track g_timeout for wispr try
Message-ID: <[email protected]>

From: Julien Massot <[email protected]>

In case we are disconnecting or removing the device,
the service will keep a ref until the timeout is reached.

Better to cancel the timeout, so that we can drop the ref,
and remove the service immediatly.
---
 src/service.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/src/service.c b/src/service.c
index 43233671..6044c601 100644
--- a/src/service.c
+++ b/src/service.c
@@ -127,6 +127,7 @@ struct connman_service {
        char *pac;
        bool wps;
        bool wps_advertizing;
+       guint online_timeout;
        int online_check_count_ipv4;
        int online_check_count_ipv6;
        bool do_split_routing;
@@ -5998,13 +5999,8 @@ static void service_rp_filter(struct connman_service 
*service,
 static void redo_wispr(struct connman_service *service,
                                        enum connman_ipconfig_type type)
 {
-       int refcount = service->refcount - 1;
-
+       service->online_timeout = 0;
        connman_service_unref(service);
-       if (refcount == 0) {
-               DBG("Service %p already removed", service);
-               return;
-       }
 
        DBG("Retrying %s WISPr for %p %s",
                __connman_ipconfig_type2string(type),
@@ -6062,7 +6058,8 @@ int __connman_service_online_check_failed(struct 
connman_service *service,
         * necessary IPv6 router advertisement messages that might have
         * DNS data etc.
         */
-       g_timeout_add_seconds(1, redo_func, connman_service_ref(service));
+       service->online_timeout = g_timeout_add_seconds(1, redo_func,
+                                       connman_service_ref(service));
 
        return EAGAIN;
 }
@@ -6481,6 +6478,15 @@ int __connman_service_connect(struct connman_service 
*service,
        return err;
 }
 
+static void cancel_online_check(struct connman_service *service)
+{
+       if (service->online_timeout > 0) {
+               connman_service_unref(service);
+               g_source_remove(service->online_timeout);
+               service->online_timeout = 0;
+       }
+}
+
 int __connman_service_disconnect(struct connman_service *service)
 {
        int err;
@@ -6494,6 +6500,8 @@ int __connman_service_disconnect(struct connman_service 
*service)
 
        __connman_stats_service_unregister(service);
 
+       cancel_online_check(service);
+
        if (service->network) {
                err = __connman_network_disconnect(service->network);
        } else if (service->type == CONNMAN_SERVICE_TYPE_VPN &&
@@ -7280,6 +7288,7 @@ void __connman_service_remove_from_network(struct 
connman_network *network)
        __connman_connection_gateway_remove(service,
                                        CONNMAN_IPCONFIG_TYPE_ALL);
 
+       cancel_online_check(service);
        connman_service_unref(service);
 }
 
-- 
2.20.1



------------------------------

Subject: Digest Footer

_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman


------------------------------

End of connman Digest, Vol 41, Issue 6
**************************************

Reply via email to