Send connman mailing list submissions to
connman@lists.01.org
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
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. AW: AW: AW: connmand[186]: Online check failed but running
dhclient manually fixes this issue
(Eswaran Vinothkumar (BEG/PJ-IOT-EL))
2. Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken (Jose Blanquicet)
3. Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken (Jose Blanquicet)
4. Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken (Daniel Wagner)
5. Re: AW: AW: AW: connmand[186]: Online check failed but
running dhclient manually fixes this issue (Daniel Wagner)
6. AW: AW: AW: AW: connmand[186]: Online check failed but
running dhclient manually fixes this issue
(Eswaran Vinothkumar (BEG/PJ-IOT-EL))
7. Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken (Jose Blanquicet)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Aug 2017 05:03:47 +0000
From: "Eswaran Vinothkumar (BEG/PJ-IOT-EL)"
<vinothkumar.eswa...@de.bosch.com>
To: Daniel Wagner <w...@monom.org>, Christophe Ronco
<c.ro...@kerlink.fr>
Cc: "connman@lists.01.org" <connman@lists.01.org>, "of...@ofono.org"
<of...@ofono.org>
Subject: AW: AW: AW: connmand[186]: Online check failed but running
dhclient manually fixes this issue
Message-ID: <59ea6e9c46df41b3ba756f153c92f...@fe-mbx1014.de.bosch.com>
Content-Type: text/plain; charset="utf-8"
Hi Christophe and Eswaran,
I just discussed this problem with Denis on IRC. Denis is quite sure the modem
is broken. To fix this, we need to add a quirk to the device driver in oFono
code base which disables the IP configuration reporting.
With this ConnMan will use DHCP in those cases.
Could you send me the exact modem description you are using? So that we can
write quirk?
Hi,
I am using TELIT 910 EUG Modem.
Regards,
Vinothkumar
Thanks,
Daniel
------------------------------
Message: 2
Date: Thu, 10 Aug 2017 08:19:37 +0000
From: Jose Blanquicet <blanqui...@gmail.com>
To: Jonah Petri <jo...@sense.com>, Daniel Wagner <w...@monom.org>
Cc: connman@lists.01.org
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken
Message-ID:
<CAFC8iJJ6f3OAjYtEUMeK512DOpZnwjFToN=4gqekq7je1yi...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Good morning,
On Wed, Aug 9, 2017 at 3:20 PM, Daniel Wagner <w...@monom.org> wrote:
>>>> I want to report an issue with connman. We set BackgroundScanning =
>>>> false in main.conf. However, I have found that this also causes connman to
>>>> give an erroneous empty response to the Scan() dbus call, potentially
>>>> permanently disabling the device.
First of all, I think we need to clarify the differences between
Background-Scan (Roaming) and Auto-Scan. Background-Scan is a
parameter used to ask wpa_supplicant to perform background scans when
we are connected for the purpose of roaming within an ESS, i.e. within
a single network block with all the APs using the same SSID. You also
need to have defined CONFIG_BGSCAN_SIMPLE=y in .config before
compiling wpa_supplicant to enable this. On the other hand, Auto-Scan
is indeed what is described in the main.conf as "BackgroundScanning"
property and takes place when we are NOT connected:
"... Background scanning will start every 5 minutes unless the scan
list is empty. In that case, a simple backoff mechanism starting from
10s up to 5 minutes will run."
However, "BackgroundScanning" property is used to enable/disable both
features Background-Scan and Auto-Scan thus it creates confusion:
52efb07a99e5 ('wifi: Specify bgscan parameters according to main.conf settings')
616abe0abcbe ('wifi: Setup autoscan according to the main.conf settings')
It is important also to remark that the mentioned backoff mechanism is
only triggered after a Technology.Scan(). It is not true such
mechanism is triggered when scan list is empty, if
"BackgroundScanning" is disabled then the scan list will remain empty
until you actively perform a Scan(), instead if you enable it the
backoff mechanism will take place. This could be Jonah's problem.
>>>> The key preconditions seem to be:
>>>> 1) wpa_supplicant reports a max_ssids > 1
This value is directly reported by your WiFi driver and could be 0 or
greater than 2 according to what was done in 6af0579c4340
('gsupplicant: Return zero for max scan SSID parameter').
>>>> 2) the computer must have been previously associated to a SSID which is
>>>> no longer visible
>>>
>>>
>>> 'previously asscioated' is from a previous run? ConnMan has been
>>> restarted but not wpa_supplicant? Or the whole box has been restarted?
>>
>>
>> In my case, the whole box has been restarted. But, from code examination,
>> if get_latest_connections() doesn't return empty, then the #2 precondition
>> is satisfied. I'm not sure all the ways that could become the case, but at
>> least the following works: associating with a network, unplugging the
>> device, unplugging the AP, then booting the device.
>
>
> Okay, the state (already connected to some network) is preserved somewhere
> persistently.
Yeah, get_latest_connections() reads the information of the latest
connections from folders {STOREDIR}/connman/wifi_* and those are
indeed persistent. Therefore, this condition is satisfied once you
have got connected to one WiFi network since you have installed
ConnMan.
>>>> 3) as above, BackgroundScanning must be set to false
>>>> This causes the logic of wifi.c:wifi_scan() to fail. In particular:
>>>> 1) wifi_scan_simple is not used, due to the above preconditions.
>>>> 2) connman requests an active scan via wpa_supplicant for the ssids
>>>> returned by get_latest_connections.
>>>> 3) connman does not request a followup passive scan, as
>>>> BackgroundScanning is turned off, which causes start_autoscan() to exit
>>>> early.
So far I can follow you.
>>>> This means that in the scenario above, connman will never see any wifi
>>>> networks. Scan() will always return an empty list, even if other SSIDs
>>>> are available. This is potentially fatal for embedded systems, so in my
>>>> view this is a very serious issue.
I could not reproduce this or at least not what I understood you are
suffering. From 802.11-2012 std: "Active scanning involves the
generation of Probe request frames and the subsequent processing of
received Probe Response frames" and from what I understood it should
not affect the results of the scanning, you should get the same
results.
The question here is: if you perform a D-Bus call for
Technology.Scan() from your client (Or connmanclt) you do not get any
service as result or instead what you mean is that when you call
Manger.GetServices() you do not get any service? Because these two
things are very different according to what I explained at the
beginning: If you disable "BackgroundScanning" and you do not actively
make a Technology.Scan() call, the service list after a while will be
empty and will remains so until you ask for another scan.
Best regards,
Jose Blanquicet
------------------------------
Message: 3
Date: Thu, 10 Aug 2017 08:25:25 +0000
From: Jose Blanquicet <blanqui...@gmail.com>
To: Sam Nazarko <em...@samnazarko.co.uk>
Cc: Jonah Petri <jo...@sense.com>, "connman@lists.01.org"
<connman@lists.01.org>, Daniel Wagner <w...@monom.org>
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken
Message-ID:
<CAFC8iJJEv=rEY4iapN6b9ntPoZjK2ixv_syq=hhuqh4u7uw...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi Sam,
On Tue, Aug 8, 2017 at 3:22 PM, Sam Nazarko <em...@samnazarko.co.uk> wrote:
> I can reproduce this issue. We wanted to disable BackgroundScanning as we
> support
> a few wireless drivers that experience disruption to the connection when
> scanning
> occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
> reports of users unable to find any WiFi networks.
What you need is to disable specifically what I explained as
Background-Scan for roaming proposes.
Here we could think to divide "BackgroundScanning" into two different
properties, one for Background-Scan another for Auto-Scan. What do
people think?
Regards,
Jose Blanquicet
------------------------------
Message: 4
Date: Thu, 10 Aug 2017 10:50:55 +0200
From: Daniel Wagner <w...@monom.org>
To: Jose Blanquicet <blanqui...@gmail.com>, Sam Nazarko
<em...@samnazarko.co.uk>
Cc: Jonah Petri <jo...@sense.com>, "connman@lists.01.org"
<connman@lists.01.org>
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken
Message-ID: <e2ec80aa-b54c-0e57-d24b-7915dcf3b...@monom.org>
Content-Type: text/plain; charset=utf-8
Hi Jose,
On 08/10/2017 10:25 AM, Jose Blanquicet wrote:
> On Tue, Aug 8, 2017 at 3:22 PM, Sam Nazarko <em...@samnazarko.co.uk> wrote:
>> I can reproduce this issue. We wanted to disable BackgroundScanning as we
>> support
>> a few wireless drivers that experience disruption to the connection when
>> scanning
>> occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
>> reports of users unable to find any WiFi networks.
>
> What you need is to disable specifically what I explained as
> Background-Scan for roaming proposes.
>
> Here we could think to divide "BackgroundScanning" into two different
> properties, one for Background-Scan another for Auto-Scan. What do
> people think?
Not sure how to address this. I personally get confused by the terms background
scan and auto scan. The name 'auto' and 'background' are like synonyms in my
ears.
Furthermore, we should be careful to add main.conf config options which are
wpa_supplicant specific. We had this discussion already for other scenarios.
Adding low level config options it to main section of main.conf should be
avoided if you ask me. We have already a bunch of them.
The only idea I have so far to allow low-level plugin specific configuration
files. We would need to move of the connnman_config_*() bits around to the
public header files. Then plugins could use such function as:
char *__connman_config_get_string(GKeyFile *key_file,
const char *group_name, const char *key, GError **error);
char **__connman_config_get_string_list(GKeyFile *key_file,
const char *group_name, const char *key, gsize *length, GError **error);
bool __connman_config_get_bool(GKeyFile *key_file,
const char *group_name, const char *key, GError **error);
The reason why I suggest to allow plugins to open the keyfiles directly is that
I don't want to read all config data in the core and then pass it to
the plugin.
Sorry this is slightly detour but I think we could make use of these
changes to factor out the wpa_supplicant config hell from main.conf.
Thanks,
Daniel
------------------------------
Message: 5
Date: Thu, 10 Aug 2017 11:05:40 +0200
From: Daniel Wagner <w...@monom.org>
To: "Eswaran Vinothkumar (BEG/PJ-IOT-EL)"
<vinothkumar.eswa...@de.bosch.com>, Christophe Ronco
<c.ro...@kerlink.fr>
Cc: "connman@lists.01.org" <connman@lists.01.org>, "of...@ofono.org"
<of...@ofono.org>
Subject: Re: AW: AW: AW: connmand[186]: Online check failed but
running dhclient manually fixes this issue
Message-ID: <e2eea629-eb75-420e-1e43-900fccaa2...@monom.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Vinothkumar,
[sorry for the last mails where I got your last name mixed up...]
On 08/10/2017 07:03 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
> Could you send me the exact modem description you are using? So that we can
> write quirk?
>
> Hi,
>
> I am using TELIT 910 EUG Modem.
Okay, maybe that is already enough. I saw that in drivers/telit.c there
is already some code to handle variants of the modem. The matching is
done on these strings.
Are there any vid/pid available fot his modem?
Thanks,
Daniel
------------------------------
Message: 6
Date: Thu, 10 Aug 2017 09:10:57 +0000
From: "Eswaran Vinothkumar (BEG/PJ-IOT-EL)"
<vinothkumar.eswa...@de.bosch.com>
To: Daniel Wagner <w...@monom.org>, Christophe Ronco
<c.ro...@kerlink.fr>
Cc: "connman@lists.01.org" <connman@lists.01.org>, "of...@ofono.org"
<of...@ofono.org>
Subject: AW: AW: AW: AW: connmand[186]: Online check failed but
running dhclient manually fixes this issue
Message-ID: <31a9ca3feb2d4b29a3facaa5514cb...@fe-mbx1014.de.bosch.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Hi Vinothkumar,
[sorry for the last mails where I got your last name mixed up...]
No issues. I could understand the problem with Indian names, difficult to
differentiate between first and last name.
On 08/10/2017 07:03 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:
> Could you send me the exact modem description you are using? So that we can
> write quirk?
>
> Hi,
>
> I am using TELIT 910 EUG Modem.
Okay, maybe that is already enough. I saw that in drivers/telit.c there is
already some code to handle variants of the modem. The matching is done on
these strings.
Are there any vid/pid available fot his modem?
Bus 001 Device 003: ID 1bc7:1201 Telit Wireless Solutions
Regards,
Vinoth
Thanks,
Daniel
------------------------------
Message: 7
Date: Thu, 10 Aug 2017 09:55:56 +0000
From: Jose Blanquicet <blanqui...@gmail.com>
To: Daniel Wagner <w...@monom.org>
Cc: Sam Nazarko <em...@samnazarko.co.uk>, Jonah Petri
<jo...@sense.com>, "connman@lists.01.org" <connman@lists.01.org>
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken
Message-ID:
<CAFC8iJKZY1wPyDM=yuuhiw+rmjsxnc8byda2cvwktifaghs...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, Aug 10, 2017 at 8:50 AM, Daniel Wagner <w...@monom.org> wrote:
> On 08/10/2017 10:25 AM, Jose Blanquicet wrote:
>> On Tue, Aug 8, 2017 at 3:22 PM, Sam Nazarko <em...@samnazarko.co.uk> wrote:
>>> I can reproduce this issue. We wanted to disable BackgroundScanning as we
>>> support
>>> a few wireless drivers that experience disruption to the connection when
>>> scanning
>>> occurs. After disabling BackgroundScanning in ConnMan 1.34, we had numerous
>>> reports of users unable to find any WiFi networks.
>>
>> What you need is to disable specifically what I explained as
>> Background-Scan for roaming proposes.
>>
>> Here we could think to divide "BackgroundScanning" into two different
>> properties, one for Background-Scan another for Auto-Scan. What do
>> people think?
>
> Not sure how to address this. I personally get confused by the terms
> background
> scan and auto scan. The name 'auto' and 'background' are like synonyms in my
> ears.
I know, it is indeed confusing.
> Furthermore, we should be careful to add main.conf config options which are
> wpa_supplicant specific. We had this discussion already for other scenarios.
> Adding low level config options it to main section of main.conf should be
> avoided if you ask me. We have already a bunch of them.
>
> The only idea I have so far to allow low-level plugin specific configuration
> files. We would need to move of the connnman_config_*() bits around to the
> public header files. Then plugins could use such function as:
>
>
> char *__connman_config_get_string(GKeyFile *key_file,
> const char *group_name, const char *key, GError **error);
>
> char **__connman_config_get_string_list(GKeyFile *key_file,
> const char *group_name, const char *key, gsize *length, GError
> **error);
>
> bool __connman_config_get_bool(GKeyFile *key_file,
> const char *group_name, const char *key, GError **error);
>
>
> The reason why I suggest to allow plugins to open the keyfiles directly is
> that
> I don't want to read all config data in the core and then pass it to
> the plugin.
>
> Sorry this is slightly detour but I think we could make use of these
> changes to factor out the wpa_supplicant config hell from main.conf.
Got it and I think you are completely right, let's keep wpa_supplicant
configuration far away from there.
Well, what we could do is to restrict the behavior of
"BackgroundScanning" to exactly how it is described in main.conf thus
only auto-scan when we are not connected. If one wants to keep
autoscan enabled and only disable background scanning for roaming
because of issues like Sam's one then one should only keep
"CONFIG_BGSCAN_SIMPLE=y" commented (As is done by default) in .config
of wpa_supplicant and there should not be need of touch main.conf at
all.
Sam, could you please try following patch, keep BackgroundScanning =
true and keep CONFIG_BGSCAN_SIMPLE=y commented for wpa_s? It should
work in your case.
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 34c16dfd4486..193267d9f398 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2083,8 +2083,7 @@ static void ssid_init(GSupplicantSSID *ssid,
struct connman_network *network)
ssid->use_wps = connman_network_get_bool(network, "WiFi.UseWPS");
ssid->pin_wps = connman_network_get_string(network, "WiFi.PinWPS");
- if (connman_setting_get_bool("BackgroundScanning"))
- ssid->bgscan = BGSCAN_DEFAULT;
+ ssid->bgscan = BGSCAN_DEFAULT;
}
static int network_connect(struct connman_network *network)
Regards,
Jose Blanquicet
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
connman@lists.01.org
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 22, Issue 9
**************************************
