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: Race condition on too fast stop&&start resulting in Error
/net/connman/technology/wifi: Not supported that does not
recovery without another restart (Daniel Wagner)
2. Re: Failing to connect to service with manual provisioning
(Daniel Wagner)
3. Re: [PATCH 01/10] vpn-agent: Implement generic D-Bus error
checker for plugins. (Jussi Laakkonen)
4. Re: [PATCH v2 04/10] openconnect: Use vpn-agent.c error
processing for VPN agent errors. (Jussi Laakkonen)
5. Re: [PATCH 08/10] provider: Implement function to set VPN
service autoconnect value (Jussi Laakkonen)
6. Re: [PATCH 10/10] vpn: Handle OperationCanceled D-Bus message
reply (Jussi Laakkonen)
----------------------------------------------------------------------
Message: 1
Date: Fri, 28 Jun 2019 12:37:56 +0200
From: Daniel Wagner <[email protected]>
To: KARBOWSKI Piotr <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Race condition on too fast stop&&start resulting in Error
/net/connman/technology/wifi: Not supported that does not recovery
without another restart
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Piotr,
On 6/13/19 6:18 PM, KARBOWSKI Piotr wrote:
> Hi,
>
> I am facing issue with connman-1.37 regarding the wireless network
> access. If I restart connman that was already running, I will get not
> working wireless connection
>
> # connmanctl scan wifi
> Error /net/connman/technology/wifi: Not supported
>
> I can reproduce it on two separated Gentoo ~amd64 systems. One has Intel
> 9462 and the other with Intel 8265. The wireless connection never
> recovery unless I restart connman one more time.
>
> If I not use restart, but stop && start with sleep 3 in between for
> example, everything works.
>
> It looks to me like a race condition with whatever connman does to
> iwlwifi device upon stopping, that is still 'on going' after connmand
> exited, and when new one starts, it lacks code to retry bringing device
> up after a delay when it fails for the first time, unless it silently
> fails inside, somewhere.
>
> Steps to reproduce:
>
> While connman is running, run /etc/init.d/connman stop &&
> /etc/init.d/connman start
>
> The `connmanctl scan wifi` will not work regardless of how long one will
> wait. The init script is the most basic one, all it does is
> starts/terminates /usr/sbin/connmand.
>
> Steps to reproduce with a workaround:
>
> While connman is running, run /etc/init.d/connman stop && sleep 3 &&
> /etc/init.d/connman start
>
> The `connmanctl scan wifi` will work after a few seconds.
Thanks for your report. I'll try to reproduce it and address it if
possible. wpa_supplicant and ConnMan is a difficult topic :).
Thanks,
Daniel
------------------------------
Message: 2
Date: Fri, 28 Jun 2019 12:46:03 +0200
From: Daniel Wagner <[email protected]>
To: Jason Tribe <[email protected]>
Cc: [email protected]
Subject: Re: Failing to connect to service with manual provisioning
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Jason,
On 6/20/19 1:34 PM, Jason Tribe wrote:
> Hi,
>
> We are using the manual method of connecting to a service, where we
> write the service config file to /var/lib/connman and then call the
> connect function on that services interface without using the agent API.
Just to make sure, you mean the provisioning file with 'service config
file'?
> The problem we are having is that this method results in a "Not
> registered" error message in most cases. The only way we can get this to
> work correctly is to disable and then enable the WiFi technology after
> writing the config file and before calling the connect function on that
> service.
I asked because if you write the config file under
/var/lib/connman/wifi_$ID/settings it's likely not to work when ConnMan
is running. But from your description it sounds like you writing the
provisiong file.
> Has anyone had a similar issue or is there a better?solution to connect
> to a service without using the agent API.
So it always works with the agent registered? If so, can you try to
comment out:
err = __connman_agent_request_passphrase_input(service,
request_input_cb,
dbus_sender,
pending);
if (service->hidden && err != -EINPROGRESS)
service->pending = pending;
in service.c:__connman_service_connect() (around line 6616).
I wonder if this makes a difference...
Thanks,
Daniel
------------------------------
Message: 3
Date: Fri, 28 Jun 2019 16:57:29 +0300
From: Jussi Laakkonen <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 01/10] vpn-agent: Implement generic D-Bus error
checker for plugins.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 6/28/19 1:01 PM, Daniel Wagner wrote:
> Hi Jussi,
>
> On 6/24/19 4:37 PM, Jussi Laakkonen wrote:
>> It is not feasible for every VPN plugin to check the errors in D-Bus
>> reply sent by VPN agent in their own way. This kind of general use makes
>> reacting to the canceled, timed out or no response replies sent by VPN
>> agent more common and less error prone.
>>
>> The check function (vpn_agent_check_and_process_reply_error()) takes in
>> the reply, callback to provider connect function and the pending D-Bus
>> message, that will be utilized by the callback
>> (vpn-provider.c:connect_cb()). This way proper notifications are passed
>> forwards and appropriate reply is sent to the caller of the VPN plugin
>> connection request (connmand). By sending the reply the caller
>> (connmand) can then disable autoconnection from the VPN to avoid
>> re-connection in case the user canceled the VPN agent dialog.
>>
>> The errors that are reacted to:
>> ? - net.connman.vpn.Agent.Error.Canceled -> ECANCELED
>> ? - org.freedesktop.DBus.Error.Timeout -> ETIMEDOUT
>> ? - org.freedesktop.DBus.Error.NoReply -> ENOMSG
>> ? - any other error from VPN agent is EACCES
>>
>> Error in VPN agent or canceling the VPN agent should not be an error in
>> the VPN provider and, therefore, set the provider state to idle. Also,
>> if task was already running stop it to avoid leaving VPN processes
>> running.
>
> Patch applied after removing the two DBG() statements. If you want to
> log the interaction please add connman_info() or connman_warn().
Oh, sorry about that, we've been using DBG() in our fork regularly and
old habits die hard. But I'll keep that in mind, thanks for the info.
We have used DBG() a lot to get info only when explicitly enabling
debugging. That is done also to keep system log cleaner in normal use.
But no worries :)
Cheers,
Jussi
------------------------------
Message: 4
Date: Fri, 28 Jun 2019 17:01:50 +0300
From: Jussi Laakkonen <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH v2 04/10] openconnect: Use vpn-agent.c error
processing for VPN agent errors.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 6/28/19 1:16 PM, Daniel Wagner wrote:
> Hi Jussi,
>
> On 6/25/19 4:30 PM, Jussi Laakkonen wrote:
>> Use vpn_agent_check_and_process_reply_error() to check and process VPN
>> agent errors. Clear callback and pending D-Bus message (user_data) if
>> error was processed to avoid calling the callback twice.
>
> Patch applied. I also rename err_int to err. I think I know why you used
> err_int. Was it avoid to clash with the jump label err? Luckeliy the
> compiler is not confused and we got this already in our code base :)
>
Your assumption is correct, labels are the cause for that. I apparently
did not check if all of those plugins had a label with the "err" name
and in some of those plugins the "err_int" was not necessary.
On retrospect, another way would have been to rename the labels to
"error:" and have the int as "err". But that is just cosmetics, I just
wanted to avoid confusion :).
Cheers,
Jussi
------------------------------
Message: 5
Date: Fri, 28 Jun 2019 17:03:59 +0300
From: Jussi Laakkonen <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 08/10] provider: Implement function to set VPN
service autoconnect value
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 6/28/19 1:26 PM, Daniel Wagner wrote:
> Hi Jussi,
>
> On 6/24/19 4:37 PM, Jussi Laakkonen wrote:
>> Add connman_provider_set_autoconnect() for setting the VPN autoconnect
>> value. If a change took place save the VPN service.
>>
>> It is imperative to save the VPN service when autoconnect changes since
>> otherwise the change is done only to run-time service settings and not
>> written to disk if user has canceled VPN agent dialog, for example.
>> Otherwise the data within connman and service file is out of sync, and
>> next restart of connman will be a race between each VPNs that were
>> attempted to connect but canceled by user.
>
> Patch applied, after..
>
>> +void connman_provider_set_autoconnect(struct connman_provider *provider,
>> +??????????????????????????????? bool flag)
>> +{
>> +??? if (provider && provider->vpn_service) {
>
> I changed this into an early leave,
>
> ????if (!provider || !provider->vpn_service)
> ??????? return;
>
> which matches with the rest of the file.
>
Oh, right, that is much cleaner and in line with rest, yes. Thanks for
cleaning this up.
Cheers,
Jussi
------------------------------
Message: 6
Date: Fri, 28 Jun 2019 17:11:08 +0300
From: Jussi Laakkonen <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 10/10] vpn: Handle OperationCanceled D-Bus message
reply
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 6/28/19 1:30 PM, Daniel Wagner wrote:
> Hi Jussi,
>
> On 6/24/19 4:37 PM, Jussi Laakkonen wrote:
>> OperationCanceled (ECANCELED) is returned by connman-vpnd if the VPN
>> agent used to input credentials for a VPN is canceled. This needs to be
>> handled in plugins/vpn.c:connect_reply() and with this error
>> autoconnect should be disabled for the VPN service.
>
> Patch applied.
>
> So I should have picked up all 10 patches and not broken them. Fingers
> crossed :)
>
I checked each modified patch. Everything seems to be in order :) I'll
apply these changes to our fork as well.
> Excellent cleanup!
>
Thanks and you are welcome.
Cheers,
Jussi
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 44, Issue 11
***************************************
