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. Changing vpn property through DBUS (Salman Ahmed)
2. Race condition on too fast stop&&start resulting in Error
/net/connman/technology/wifi: Not supported that does not
recovery without another restart (KARBOWSKI Piotr)
3. Failure state reset after wifi authentication denied
(Damien Miliche)
4. Re: Failure state reset after wifi authentication denied
(Damien Miliche)
----------------------------------------------------------------------
Message: 1
Date: Thu, 13 Jun 2019 10:59:37 +0200
From: Salman Ahmed <[email protected]>
To: [email protected]
Subject: Changing vpn property through DBUS
Message-ID:
<CAMAf_5hBxoZNvG=0q-8dn4tdpdhhofn-2gz_ov66k4swpgd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Previous mail didn't appear as post.
Hello,
I am trying to change the properties of a vpn conection under connman
(through DBUS) but I am running into an error
e.g) This call succeeds and I am presented with the properties of the vpn
connection
dbus-send --system --dest=net.connman.vpn --type=method_call --print-reply
/net/connman/vpn/connection/uk_london_privateinternetaccess_com_privateinternetaccess_com
net.connman.vpn.Connection.GetProperties
Using d-feet I see that the SetProperty is defined as SetProperty (String
name, Variant value)->()
But if I do SetProperty like this
dbus-send --system --dest=net.connman.vpn --type=method_call --print-reply
/net/connman/vpn/connection/uk_london_privateinternetaccess_com_privateinternetaccess_com
net.connman.vpn.Connection.SetProperty string:Name variant:string:"NewName"
I get error > Error net.connman.Error.NotSupported: Not supported
I also tried it with the python test
./vpn-property
uk_london_privateinternetaccess_com_privateinternetaccess_com Name NewName
net.connman.Error.NotSupported: Not supported
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20190613/059c8b7a/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 13 Jun 2019 18:18:53 +0200
From: KARBOWSKI Piotr <[email protected]>
To: "[email protected]" <[email protected]>
Subject: 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
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.
-- Piotr.
------------------------------
Message: 3
Date: Thu, 13 Jun 2019 18:50:45 +0200
From: Damien Miliche <[email protected]>
To: [email protected]
Subject: Failure state reset after wifi authentication denied
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I've encountered a situation where an wifi Access Point denies the
authentication of my client ("denied authentication (status 17)").
Connman considers that as a failure, and the service I was trying to
connect enters the 'failure' state, with error 'connect-failed'.
From then, after only one attempt, despite the background scanning,
connman never tries to reconnect automatically, even if the service is
configured as 'AutoConnect' and the corresponding SSID appears in the
scan results: it looks like it is ignored.
Is that normal behaviour?
Is there a way for connman to consider the failed service in subsequent
automatic scan results (exponential bg scan) to retry connecting?
The only way I found so far is to manually trigger a connection, but
that is not acceptable for unattended device... :s
Thanks in advance for your help.
Kind regards,
--
Damien
------------------------------
Message: 4
Date: Thu, 13 Jun 2019 20:31:57 +0200
From: Damien Miliche <[email protected]>
To: [email protected]
Subject: Re: Failure state reset after wifi authentication denied
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I found out that my connection problem has appeared after this commit:
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=6245582d0dc9a3f47a6880dabf437ee7c351caef.
Especially, while the message commit seems to apply to my case (status
code 17), the piece of code in function handle_assoc_status_code is not
applicable for triggering retries: the condition 'wifi->state ==
G_SUPPLICANT_STATE_ASSOCIATING' is not satisfied, as the authentication
denial happens in my case during state G_SUPPLICANT_STATE_AUTHENTICATING.
Moreover, at that state, wpa_supplicant does not provide the
authentication status code in the DBUS PropertyChanged signal, that
would indicate the reason of the denial (17 -
WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA), as the assoc status code
(AssocStatusCode) would be after a failed association.
Any suggestion of how to fix this?
Would patching both connman and wpa_supplicant in a similar way to
commit 6245582d0dc9a3f47a6880dabf437ee7c351caef of connman and commit
c7fb678f3109e62af1ef39be9b12bf8370c35bde of hostapd/wpa_supplicant, but
for CTRL-EVENT-AUTH-REJECT event / G_SUPPLICANT_STATE_AUTHENTICATING
state, be an acceptable solution?
Thanks in advance for your help.
Kr,
--
Damien
On 13/06/2019 18:50, Damien Miliche wrote:
> Hi,
>
>
> I've encountered a situation where an wifi Access Point denies the
> authentication of my client ("denied authentication (status 17)").
>
> Connman considers that as a failure, and the service I was trying to
> connect enters the 'failure' state, with error 'connect-failed'.
>
> From then, after only one attempt, despite the background scanning,
> connman never tries to reconnect automatically, even if the service is
> configured as 'AutoConnect' and the corresponding SSID appears in the
> scan results: it looks like it is ignored.
>
> Is that normal behaviour?
>
> Is there a way for connman to consider the failed service in subsequent
> automatic scan results (exponential bg scan) to retry connecting?
>
> The only way I found so far is to manually trigger a connection, but
> that is not acceptable for unattended device... :s
>
>
> Thanks in advance for your help.
>
>
> Kind regards,
>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 44, Issue 5
**************************************
