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: When BackgroundScanning = false, connman's Scan() dbus
method is broken (Jonah Petri)
2. Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken (Jonah Petri)
3. Re: [PATCH 2/2] service: add mDNS support on per-interface
basis. (Daniel Wagner)
4. Re: [PATCH 1/2] resolver: add support for systemd-resolved.
(Daniel Wagner)
5. Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken (Daniel Wagner)
6. Re: [PATCH v2] gsupplicant: Updates to handling of security
change (Daniel Wagner)
7. Re: [PATCH 1/2] resolver: add support for systemd-resolved.
(Puustinen, Ismo)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Oct 2017 20:07:10 -0400
From: Jonah Petri <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: Daniel Wagner <[email protected]>, [email protected]
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Jose,
Apologies for the delay!
> On Sep 25, 2017, at 2:58 PM, Jose Blanquicet <[email protected]> wrote:
>
> Hi Jonah,
>
> On Fri, Sep 22, 2017 at 9:17 PM, Jonah Petri <[email protected]> wrote:
>> I tested the patch you provided, and it does appear to solve the problem as
>> described. I'll promote that patch into my dev fleet, and let you know if I
>> notice any other bad behaviors.
>>
>>
>> I tested the patch you posted. While I never saw any dbus-requested scans
>> failing, I did notice an increase in the number of my dev units falling
>> offline after a reboot.
>
> Sorry, I am not sure I got what you mean here :(. Could you please
> rephrase this and give me more details?
I applied the patch, and ran it for some days on a fleet of testing devices.
As a part of the testing, I rebooted the devices regularly, under various wifi
conditions, and noted that some of them did not re-associate with the wifi
network successfully upon reboot.
>
>> In each case I've tested, as soon as dbus Scan()
>> was initiated, the previously associated network was seen and joined. While
>> I haven't looked for exactly where, I am guessing that there is some hole in
>> the connman startup logic where it needs to request a wpa_s Passive scan as
>> well.
>
> I assume you mean that at the start-up you see a D-Bus scan call from
> ConnMan to wpa_s and a successive re-connection to a known WiFi
> network? If so, yes, that's desired start-up procedure.
That?s not what I meant, sorry! To clarify, I did see connman send a scan
request to wpa_s, but it was an active scan. This scan (likely because of
environmental conditions) did not find the desired network. In that case, the
unit apparently did not do any sort of followup scans. Later, I manually
issued a Scan() call to connman, which (as your patch specified) issued a
passive scan to wpa_s. This scan happened to yield the desired network, and
connman immediately associated with it.
>
>> Perhaps it would be best to always follow an active scan with a passive one?
>> Or perhaps BackgroundScanning should just be forced to 'true'?
>
> Follow an active scan with only one passive scan in case
> BackgroundScanning='false' is indeed the best solution. I thought I
> would be able to find time to work on that solution but it haven't
> yet, it has not been an ease time. This is the idea I have in mind:
>
> Current behaviour with BackgroundScanning='True' is:
> D-Bus scan request or at start-up of system
> Launch an active scan
> 3 seconds -> Launch passive scan
> 9 seconds -> Launch passive scan
> 27 seconds -> Launch passive scan
> 81 seconds -> Launch passive scan
> 243 seconds -> Launch passive scan
> 300 seconds -> Launch passive scan
> 300 seconds -> Launch passive scan
> ...
> Continue each 300 seconds unless you perform a new D-Bus scan call
> which will cause the procedure to restart from 3 seconds.
>
> With BackgroundScanning='False' the idea would be:
> D-Bus scan request or at start-up of system
> Launch an active scan
> 3 seconds -> Launch passive scan
> Stop. No more scanning: 3 seconds would be enough for ConnMan to
> reconnect to a known service in case there is one of them in range.
> New D-Bus scan request from user
> Launch an active scan
> 3 seconds -> Launch passive scan
> Stop.
Ah, maybe I have misinterpreted the meaning of BackgroundScanning!
I thought it meant that connman would not issue scans when it was already
connected to a WiFi network. I had assumed that it would continue to scan for
the requested WiFi network when not connected. From your description above, it
seems I was wrong! If that?s the case, I think I really do want
BackgroundScanning, as networks can be down from time to time, and I would want
my devices to recover by detecting the configured network when it becomes
available again, and reconnecting to it.
>
>> It seems that connman may be depending too much on somewhat undocumented
>> behaviors of wpa_supplicant and the cfg80211 driver layers, and it's being
>> exposed to these bugs.
>
> Unfortunately, yes. wpa_s is the current way to communicate with the
> WiFi chip thus we have to deal with it. There are a bunch of things
> could have been implemented better in wpa_s. For example, this
> scanning logic should be something completely managed by the WiFi
> daemon and not by ConnMan.
Agreed, but yes, we must just deal with these things. :D
Jonah
------------------------------
Message: 2
Date: Mon, 2 Oct 2017 20:14:57 -0400
From: Jonah Petri <[email protected]>
To: Jose Blanquicet <[email protected]>
Cc: Daniel Wagner <[email protected]>, [email protected]
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Jose,
> On Oct 1, 2017, at 2:13 PM, Jose Blanquicet <[email protected]> wrote:
>
> Hi Jonah,
>
> I implemented a patch following above description. In addition, the
> patch takes into account that ConnMan will only ask for an active scan
> if user has connected to at least one WiFi network in the past and the
> WiFi chipset support active scanning. If those conditions are not
> true, ConnMan will always ask for a passive scan.
This approach seems useful to me. Can I also request a clarification on the
BackgroundScanning section of connman.conf(5)?
I would suggest something like:
BackgroundScanning=true|false
Enable background scanning. Default is true. 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.
+ When BackgroundScanning is false, ConnMan will not actively
+ scan for or configured networks, even when disconnected,
+ unless it is explicitly requested via a Scan() invocation
+ via D-Bus.
Many thanks for your work on this!
Jonah
------------------------------
Message: 3
Date: Tue, 3 Oct 2017 12:58:22 +0200
From: Daniel Wagner <[email protected]>
To: "Puustinen, Ismo" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [PATCH 2/2] service: add mDNS support on per-interface
basis.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 10/02/2017 01:44 PM, Puustinen, Ismo wrote:
> On Sun, 2017-10-01 at 15:45 +0200, Daniel Wagner wrote:
>>> busctl call net.connman /net/connman/service/service_name \
>>> net.connman.Service SetProperty sv mDNS.Configuration \
>>> a{sv} 1 Method s enabled
>>
>> Could you also extend the connmanctl tool? Also having a simple test
>> script would hurt.
>
> Sure, I can extend the tool.
>
>> On my system I get for the above command:
>>
>> Method "SetProperty" with signature "sv" on interface
>> "net.connman.Service" doesn't exist
>>
>> Any idea what is going wrong?
>
> My guess is that you didn't change the "service_name" with the actual
> service name in the D-Bus object path. For me, the command would be
Oh man, I feel stupid.
> busctl call net.connman /net/connman/service/ethernet_0008a209bb0f_cable
> net.connman.Service SetProperty sv mDNS.Configuration a{sv} 1 Method s enabled
>
> because the service which I want to configure is called
> "ethernet_0008a209bb0f_cable" by connman.
Let me try this again with the right D-Bus path :)
> I'll fix the style issues and resubmit the patches.
Excellent!
Thanks,
Daniel
------------------------------
Message: 4
Date: Tue, 3 Oct 2017 13:07:50 +0200
From: Daniel Wagner <[email protected]>
To: Patrik Flykt <[email protected]>, Ismo Puustinen
<[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 1/2] resolver: add support for systemd-resolved.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 10/02/2017 03:08 PM, Patrik Flykt wrote:
> Actually, if we leave resolver.c as it is, and instead conditionally
> compile src/dnsproxy.c or src/systemd-resolved.c, wouldn't that solve
> most of the code changes in a cleaner way? The "API" would then be the
> connman_dnsproxy_* functions in connman.h, that could then move to
> /include instead?
I like this idea.
BTW, do we want to support both resolve mechanism at the same time? If
not we could have a configure switch and don't have to introduce a new
command line option. Furthermore, we don't increase the size of ConnMan
for everyone unnecessarily.
Thanks,
Daniel
------------------------------
Message: 5
Date: Tue, 3 Oct 2017 13:28:51 +0200
From: Daniel Wagner <[email protected]>
To: Jose Blanquicet <[email protected]>, Jonah Petri
<[email protected]>
Cc: [email protected]
Subject: Re: When BackgroundScanning = false, connman's Scan() dbus
method is broken
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jose,
On 10/01/2017 08:13 PM, Jose Blanquicet wrote:
> I tested the four cases and ConnMan is doing what I described above. I
> will keep the patch applied in my systems and I would like to ask
> Daniel to do it too in order to check everything continue working as
> it should :)
Can you resend the patch. I got it white space damaged and with my hand
editing it didn't get any better :)
Maybe you could also pick up Jonah's doc update too and send it as
proper patch series.
Thanks,
Daniel
------------------------------
Message: 6
Date: Tue, 3 Oct 2017 13:38:38 +0200
From: Daniel Wagner <[email protected]>
To: Harish Jenny K N <[email protected]>
Cc: Jose Blanquicet <[email protected]>, [email protected]
Subject: Re: [PATCH v2] gsupplicant: Updates to handling of security
change
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 10/01/2017 08:15 PM, Jose Blanquicet wrote:
> On Sun, Oct 1, 2017 at 3:48 PM, Daniel Wagner <[email protected]> wrote:
>> Harish Jenny K N <[email protected]> writes:
>>
>>> Changing of security type of one BSS is resulting in removing of
>>> GSupplicantNetwork and other BSSs objects in the group.
>>> The corresponding entries for other BSS in the same group are not
>>> removed in other hash tables like bss_mapping and interface->bss_mapping.
>>> This commit only deletes the network when there is a single entry in
>>> network->bss_table during change in security for one bss.
>>> This commit also avoids accessing any deleted bss object when reply
>>> is got from async dbus call, by deleting any pending dbus calls
>>> associated with the bss object.
>>
>> Jose, are you happy with this version? I'll apply it when I get your
>> ACK.
>
> Yes, it is fine, you can go ahead.
I applied the patch. I realized the comments are not following our
normal coding style so I took the liberty reformatting comments and
commit message slightly.
Thanks,
Daniel
------------------------------
Message: 7
Date: Tue, 3 Oct 2017 13:57:21 +0000
From: "Puustinen, Ismo" <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [PATCH 1/2] resolver: add support for systemd-resolved.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On Tue, 2017-10-03 at 13:07 +0200, Daniel Wagner wrote:
> On 10/02/2017 03:08 PM, Patrik Flykt wrote:
> > Actually, if we leave resolver.c as it is, and instead
> > conditionally
> > compile src/dnsproxy.c or src/systemd-resolved.c, wouldn't that
> > solve
> > most of the code changes in a cleaner way? The "API" would then be
> > the
> > connman_dnsproxy_* functions in connman.h, that could then move to
> > /include instead?
>
> I like this idea.
>
> BTW, do we want to support both resolve mechanism at the same time?
> If
> not we could have a configure switch and don't have to introduce a
> new
> command line option. Furthermore, we don't increase the size of
> ConnMan
> for everyone unnecessarily.
Ok, I did a first attempt in how this idea might look like in code. The
patches contain only the systemd-resolved DNS integration. Let's do the
mDNS stuff only when this is done so that we don't have too many balls
in the air at the same time.
Ismo
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 24, Issue 5
**************************************
