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: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment (Daniel Wagner)
2. Re: Hidden Wifi with several AP (Daniel Wagner)
3. Re: [PATCH] service: Don't auto connect if error is set for
service. (Daniel Wagner)
4. Re: Hidden Wifi with several AP (Thomas Baron)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Dec 2016 20:02:00 +0100
From: Daniel Wagner <[email protected]>
To: Shrikant Bobade <[email protected]>
Cc: [email protected]
Subject: Re: Connman v1.33 with systemd v230 : experiencing delay in
IP assignment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Shrikant,
It looks like your email client sends a plain text and as HTML too. As
with may Linux related mailing list we prefer plain text message. Could
you please check your settings. Thanks.
On 12/22/2016 02:07 PM, Shrikant Bobade wrote:
> getrandom(0x7ef1ac40, 1, GRND_NONBLOCK) = -1 EAGAIN (Resource temporarily
> unavailable)
> execution just stuck at this point..
getrandom returns immediately with GRND_NONBLOCK. It doesn't block. The
library or whatever is blocking. The strace doesn't really help here.
Can you try to get a complete stacktrace, maybe using gdb?
>> I think I don't really understand what you describe here. Does
>> 'attempt' mean the user/application tries to tell ConnMan establish
>> a connection and this is done using the D-Bus API. Or do you mean
>> the auto connect state machine?
>
> ok, adding the details below..
>
> using systemd as init-manager, with connman.service status check
> observed no activity for few mins(w.r.to <http://w.r.to> above case of
> strace getrandom), internally observed during this time connman.service
> get re-started and we can see new instance of connmand..i.e. attempt
> during 2 to 3 attemps/re-start of connman.service when the target
> entropy reached nearly between 10 to 30 range got the getrandom hang
> resolved..with further connman execution getting the ip assignment, so
> actual delay happening during multiple attempts for pass-through of
> getrandom.
From the strace it doesn't look like the kernel blocks. Without a real
stacktrace we can just do some wild guessing.
> Now to resolve the getrandom hang, used rng-tools, with rngd running via
> rngd.service(before connman.service) getting available entropy between
> 3k to 4k, & call to getrandom getting passed easily, so almost no delay
> in ip assignment from user point of view.
Still I don't get where we can block for the IP assigment. The wispr
code is called _after_ the ip assignment. So what's holding up our IP
assignement.
Can you start ConnMan with
CONNMAN_DHCP_DEBUG=1 CONNMAN_DHCPV6_DEBUG=1 ./connman -d -n
?
Uuuuuh, I think I found it gdhcp/common.c:
#define URANDOM "/dev/urandom"
static int random_fd = -1;
int dhcp_get_random(uint64_t *val)
{
int r;
if (random_fd < 0) {
random_fd = open(URANDOM, O_RDONLY);
if (random_fd < 0) {
r = -errno;
*val = random();
return r;
}
}
if (read(random_fd, val, sizeof(uint64_t)) < 0) {
r = -errno;
*val = random();
return r;
}
return 0;
}
So for a simple test, can you change the define to
#define URANDOM "/dev/random"
and see if you still block?
cheers,
daniel
------------------------------
Message: 2
Date: Thu, 22 Dec 2016 20:09:43 +0100
From: Daniel Wagner <[email protected]>
To: Thomas Baron <[email protected]>, [email protected]
Subject: Re: Hidden Wifi with several AP
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Thomas,
On 12/22/2016 10:40 AM, Thomas Baron wrote:
> I'm using connman (1.33) on a raspberry pi 3B to connect to a hidden
> wifi. While this is working fine there is an strange behavior here :
> after the connection is established (using wpa_supplicant), few seconds
> after connman switch to another AP which is broadcasting the same SSID
> (actually there are several AP on the same network at that place). Once
> this second connection is made connman stays connected properly.
> The WiFi configuration is set on /var/lib/connman/wifi.config (with
> Hidden = true on the relevant service_wifi).
Long time I looked into the roaming part. Let's see if I can help you here.
Is this only for hidden networks or do observe this also for normal
networks?
> Extract of the relevant logs is below :
>
> Dec 22 08:00:22 connmand[424]: Connection Manager version 1.33
> connmand[424]: Adding configuration wifi
> connmand[424]: Adding service configuration wifi_2458
> [...]
> systemd[1]: Started WPA supplicant.
> connmand[424]: wlan0 {update} flags 36931 <UP,RUNNING>
> wpa_supplicant[443]: wlan0: Trying to associate with 40:18:b1:0b:65:15
> (SSID='name_of_the_ssid' freq=2437 MHz)
> wpa_supplicant[443]: wlan0: Associated with 40:18:b1:0b:65:15
> wpa_supplicant[443]: wlan0: WPA: Key negotiation completed with
> 40:18:b1:0b:65:15 [PTK=CCMP GTK=TKIP]
> wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to
> 40:18:b1:0b:65:15 completed [id=0 id_str=]
> connmand[424]: wlan0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
> Dec 22 08:00:25 connmand[424]: ntp: time slew -0.215447 s
> [...] (nothing here related to either connman or wpa_supplicant)
> Dec 22 08:00:29 wpa_supplicant[443]: wlan0: Trying to associate with
> 00:19:77:3a:d1:54 (SSID='name_of_the_ssid' freq=2462 MHz)
> connmand[424]: wlan0 {RX} 239 packets 79003 bytes
> connmand[424]: Probably roaming right now! Staying connected...
> wpa_supplicant[443]: wlan0: Associated with 00:19:77:3a:d1:54
> wpa_supplicant[443]: wlan0: WPA: Key negotiation completed with
> 00:19:77:3a:d1:54 [PTK=CCMP GTK=TKIP]
> wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to
> 00:19:77:3a:d1:54 completed [id=0 id_str=]
> connmand[424]: wlan0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
>
> Regarding the signal strengh with iwlist : Quality=36/70 Signal
> level=-74 dBm for 40:18:B1:0B:65:15 and Quality=46/70 Signal level=-64
> dBm for 00:19:77:3A:D1:54
>
> So is it an expected behavior ?If yes why and is it connman,
> wpa_supplicant or the AP which take the decision to switch AP ?
The roaming decission are taken by wpa_supplicant. ConnMan just tries to
follow up. As you can see, we try to figure from the "Propably
roaming..." message that wpa_supplicant is doing something. The states
transitions exposed by wpa_supplicant are not complete and sometimes we
just need to guess.
> Is there
> a way to force connman to stay on the first AP and only switch if it
> doesn't catch the signal anymore ?
You might want to enable the wpa_supplicant debug features and see if
there is some pointers what's going on. Also make sure you use a
bleeding edge version of wpa_supplicant (e.g. compile the git version)
cheers,
daniel
------------------------------
Message: 3
Date: Thu, 22 Dec 2016 21:00:36 +0100
From: Daniel Wagner <[email protected]>
To: Saurav Babu <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH] service: Don't auto connect if error is set for
service.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Saurav,
On 12/22/2016 11:18 AM, Saurav Babu wrote:
> In the following scenario:
> 1. Device gets connected to an AP.
> 2. Goto AP's settings page and add device's MAC address in block list
> 3. Device gets disconnected with AP.
> 4. Auto Connection is again triggered with AP.
> In above scenario steps 3 and 4 are repeated infintely even though
> device would never connect to AP because it's MAC address is added in
> block list of AP.
> On the first disconnection connect-failed error is set. This patch only
> blocks auto connection whenever an error is set for the service.
service_indicate_state() {
[...]
switch (new_state) {
[...]
case CONNMAN_SERVICE_STATE_DISCONNECT:
set_error(service, CONNMAN_SERVICE_ERROR_UNKNOWN);
[...]
}
[...]
}
Is that the source of setting the error variable to
CONNMAN_SERVICE_ERROR_UNKNOWN?
>From a quick look at the pluging tells me that we don't propagate
or use the disconnect reason code at all. I suspect we would get
some hint why the disconnect happened. For example if we see reason
code 4 "Disassociated due to inactivity" would be a non-error reason and
we would be allowed to reconnect. See table 8-36 in the IEEE 802.11-2012 spec.
Do you see a reason code in the above scenario?
> ---
> src/service.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/service.c b/src/service.c
> index 737a39f..e6fdef8 100644
> --- a/src/service.c
> +++ b/src/service.c
> @@ -3733,6 +3733,9 @@ static bool is_ignore(struct connman_service *service)
> if (service->state == CONNMAN_SERVICE_STATE_FAILURE)
> return true;
>
> + if (service->error != CONNMAN_SERVICE_ERROR_UNKNOWN)
> + return true;
> +
> if (!is_ipconfig_usable(service))
> return true;
Looking at the auto_connect_service() code we have following:
if (is_ignore(service) || service->state !=
CONNMAN_SERVICE_STATE_IDLE)
continue;
The service is in CONNMAN_SERVICE_STATE_IDLE state and not in
CONNMAN_SERVICE_STATE_FAILURE. If so is_ignored() doesn't need to be updated
(which I would prefer because we are looking only on the service state
there and not the newtork state)
So from this, should we set the service state to FAILURE if we have
a network error code?
Thanks,
Daniel
------------------------------
Message: 4
Date: Fri, 23 Dec 2016 08:30:59 +0100
From: Thomas Baron <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: [email protected]
Subject: Re: Hidden Wifi with several AP
Message-ID:
<cal8jyx5rqbs+mko+jw8ttzeqoklgepgbgwraqch-nv41rgx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
Thanks for helping.
2016-12-22 20:09 GMT+01:00 Daniel Wagner <[email protected]>:
> Hi Thomas,
>
> On 12/22/2016 10:40 AM, Thomas Baron wrote:
>
>> I'm using connman (1.33) on a raspberry pi 3B to connect to a hidden
>> wifi. While this is working fine there is an strange behavior here :
>> after the connection is established (using wpa_supplicant), few seconds
>> after connman switch to another AP which is broadcasting the same SSID
>> (actually there are several AP on the same network at that place). Once
>> this second connection is made connman stays connected properly.
>> The WiFi configuration is set on /var/lib/connman/wifi.config (with
>> Hidden = true on the relevant service_wifi).
>>
>
> Long time I looked into the roaming part. Let's see if I can help you here.
>
> Is this only for hidden networks or do observe this also for normal
> networks?
>
This is happening only for hidden networks.
>
> Extract of the relevant logs is below :
>>
>> Dec 22 08:00:22 connmand[424]: Connection Manager version 1.33
>> connmand[424]: Adding configuration wifi
>> connmand[424]: Adding service configuration wifi_2458
>> [...]
>> systemd[1]: Started WPA supplicant.
>> connmand[424]: wlan0 {update} flags 36931 <UP,RUNNING>
>> wpa_supplicant[443]: wlan0: Trying to associate with 40:18:b1:0b:65:15
>> (SSID='name_of_the_ssid' freq=2437 MHz)
>> wpa_supplicant[443]: wlan0: Associated with 40:18:b1:0b:65:15
>> wpa_supplicant[443]: wlan0: WPA: Key negotiation completed with
>> 40:18:b1:0b:65:15 [PTK=CCMP GTK=TKIP]
>> wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to
>> 40:18:b1:0b:65:15 completed [id=0 id_str=]
>> connmand[424]: wlan0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
>> Dec 22 08:00:25 connmand[424]: ntp: time slew -0.215447 s
>> [...] (nothing here related to either connman or wpa_supplicant)
>> Dec 22 08:00:29 wpa_supplicant[443]: wlan0: Trying to associate with
>> 00:19:77:3a:d1:54 (SSID='name_of_the_ssid' freq=2462 MHz)
>> connmand[424]: wlan0 {RX} 239 packets 79003 bytes
>> connmand[424]: Probably roaming right now! Staying connected...
>> wpa_supplicant[443]: wlan0: Associated with 00:19:77:3a:d1:54
>> wpa_supplicant[443]: wlan0: WPA: Key negotiation completed with
>> 00:19:77:3a:d1:54 [PTK=CCMP GTK=TKIP]
>> wpa_supplicant[443]: wlan0: CTRL-EVENT-CONNECTED - Connection to
>> 00:19:77:3a:d1:54 completed [id=0 id_str=]
>> connmand[424]: wlan0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
>>
>> Regarding the signal strengh with iwlist : Quality=36/70 Signal
>> level=-74 dBm for 40:18:B1:0B:65:15 and Quality=46/70 Signal level=-64
>> dBm for 00:19:77:3A:D1:54
>>
>> So is it an expected behavior ?If yes why and is it connman,
>> wpa_supplicant or the AP which take the decision to switch AP ?
>>
>
> The roaming decission are taken by wpa_supplicant. ConnMan just tries to
> follow up. As you can see, we try to figure from the "Propably roaming..."
> message that wpa_supplicant is doing something. The states transitions
> exposed by wpa_supplicant are not complete and sometimes we just need to
> guess.
>
> Is there
>> a way to force connman to stay on the first AP and only switch if it
>> doesn't catch the signal anymore ?
>>
>
> You might want to enable the wpa_supplicant debug features and see if
> there is some pointers what's going on. Also make sure you use a bleeding
> edge version of wpa_supplicant (e.g. compile the git version)
>
Thanks, I will enable the wpa_supplicant debug options. As it is used in
our prod environnement I'm using the raspbian stable wpa_supplicant at the
moment (v2.3) but I will try the latest available to see if it helps.
>
> cheers,
> daniel
>
Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20161223/2c213c82/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 14, Issue 27
***************************************
