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: Error "wifi: No carrier" only to connman (Jun Nie)
2. Re: Error "wifi: No carrier" only to connman (Daniel Wagner)
3. disconnect_code == 1 from wpa_s results in wrong state in
wifi tech (Henrik Persson)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Mar 2019 12:16:17 +0800
From: Jun Nie <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Error "wifi: No carrier" only to connman
Message-ID:
<cabymucmdx4ucnjcf0abswgvqfz3ugfh5ldceh3n-8bhbnuu...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Daniel Wagner <[email protected]> ?2019?3?6??? ??11:33???
>
> > I use this command as my version does not support -s.
> > wpa_supplicant -u -t -ddd 2>&1 > /tmp/wpa.log &
> >
> > Thanks for the instruction! It seems a wpa_supplicant communication
> > issue. For the first scan operations on boot up, there is not scan
> > record in wpa_supplicant log. After disable/enable cycle, I still see
> > "No carrier" issue, but there is scan record in wpa_supplicant log
> > actually. And the following scan operations always success. Past
> > bY9K5DVj48 only contain log for "No carrier" cases, but you can find
> > scan operation in the bottom. Is this a wpa_supplicant bug?
> > https://paste.ubuntu.com/p/bY9K5DVj48/
>
> That might be the case. I have to read up again how the whole scan API
> is supposed to work. It is extremely tricky.
>
> At least wpa_s is well known to be buggy, so the simplest thing is to
> swap wpa_s with a newer or older version and see if you get a different
> behavior.
I switch wpa_s version from 2.7 to 2.6, I still see the bug. 2.5 fail
to pass build on yocto. Then I swith dbus_1.12.10 to dbus_1.12.8,
still see the bug. So I guess it is not due to version issue. I am
working on IMX7D platform, while on another IMX8 platform with same
user space software, this bug is observed. I am not sure whether it
due to any configuration of wpa_s or dbus?
Jun
------------------------------
Message: 2
Date: Thu, 7 Mar 2019 09:07:12 +0100
From: Daniel Wagner <[email protected]>
To: Jun Nie <[email protected]>
Cc: connman <[email protected]>
Subject: Re: Error "wifi: No carrier" only to connman
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 07.03.19 05:16, Jun Nie wrote:
>> At least wpa_s is well known to be buggy, so the simplest thing is to
>> swap wpa_s with a newer or older version and see if you get a different
>> behavior.
>
> I switch wpa_s version from 2.7 to 2.6, I still see the bug. 2.5 fail
> to pass build on yocto. Then I swith dbus_1.12.10 to dbus_1.12.8,
> still see the bug. So I guess it is not due to version issue. I am
> working on IMX7D platform, while on another IMX8 platform with same
> user space software, this bug is observed. I am not sure whether it
> due to any configuration of wpa_s or dbus?
I don't think this is D-Bus related. Well, at least we know now for sure :)
What WiFi chip is used on the IMX7D and IMX8 platform? Is it the same or
a different one? Also which kernel version are you using? Is it one of
those infamous Freescale kernels?
In case the driver is buggy you could try to monitor the interaction
between wpa_supplicant and the kernel using iwmon:
https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/README#n182
So we or better you a just debugging one layer lower now :)
------------------------------
Message: 3
Date: Thu, 7 Mar 2019 11:44:17 +0000
From: Henrik Persson <[email protected]>
To: connman <[email protected]>
Cc: Olof Winge <[email protected]>
Subject: disconnect_code == 1 from wpa_s results in wrong state in
wifi tech
Message-ID:
<he1pr1001mb12267c0a9b6f9a276ca0f7d5f7...@he1pr1001mb1226.eurprd10.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Found a bit of a strangeness in one of our systems connected to a Fritz!Box
7590 which seems to cause wpa_supplicant to periodically disconnect us and
throw disconnect_reason = 1. Like this:
Mar? 6 14:08:31 lev daemon.info wpa_supplicant[781]: mlan0: WPA: Group rekeying
completed with 44:4e:xxx:33 [GTK=CCMP]
Mar? 6 14:18:31 lev daemon.info wpa_supplicant[781]: mlan0: WPA: Group rekeying
completed with 44:4e:xxx:33 [GTK=CCMP]
Mar? 6 14:28:31 lev daemon.info wpa_supplicant[781]: mlan0: WPA: Group rekeying
completed with 44:4e:xxx:33 [GTK=CCMP]
Mar? 6 14:37:42 lev daemon.info wpa_supplicant[781]: mlan0:
CTRL-EVENT-DISCONNECTED bssid=44:4e:xxx:33 reason=3
Mar? 6 14:37:42 lev daemon.info wpa_supplicant[781]: mlan0:
CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Mar? 6 14:37:42 lev daemon.info wpa_supplicant[781]: mlan0:
CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE
Mar? 6 14:37:45 lev daemon.info wpa_supplicant[781]: mlan0: Trying to associate
with 44:4e:xxx:34 (SSID='FRITZ!Box 7590 [redacted]' freq=2412 MHz)
Mar? 6 14:37:46 lev daemon.info wpa_supplicant[781]: mlan0: Associated with
44:4e:xxx:34
Mar? 6 14:37:46 lev daemon.info wpa_supplicant[781]: mlan0:
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mar? 6 14:37:46 lev daemon.info wpa_supplicant[781]: mlan0: WPA: Key
negotiation completed with 44:4e:xxx:34 [PTK=CCMP GTK=CCMP]
Mar? 6 14:37:46 lev daemon.info wpa_supplicant[781]: mlan0:
CTRL-EVENT-CONNECTED - Connection to 44:4e:xxx:34 completed [id=1 id_str=]
Mar? 6 14:37:46 lev daemon.info wpa_supplicant[781]: mlan0:
CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Mar? 6 14:38:35 lev daemon.info wpa_supplicant[781]: mlan0:
CTRL-EVENT-DISCONNECTED bssid=44:4e:xxx:34 reason=1
Mar? 6 14:38:35 lev daemon.info wpa_supplicant[781]: mlan0:
CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
This produces results in:
root:~# busctl call net.connman / net.connman.Manager GetTechnologies
a(oa{sv}) 3 "/net/connman/technology/cellular" 5 "Name" s "Cellular" "Type" s
"cellular" "Powered" b true "Connected" b true "Tethering" b false
"/net/connman/technology/wifi" 5 "Name" s "WiFi" "Type" s "wifi" "Powered" b
true "Connected" b true "Tethering" b false "/net/connman/technology/ethernet"
5 "Name" s "Wired" "Type" s "ethernet" "Powered" b true "Connected" b false
"Tethering" b false
root:~# busctl call net.connman / net.connman.Manager GetServices
a(oa{sv}) 1 "/net/connman/service/cellular_2404xxxx_context1" 24 "Type" s
"cellular" "Security" as 0 "State" s "ready" "Strength" y 6 "RSSI" n 0
"Favorite" b true "Immutable" b false "AutoConnect" b false "Name" s "Telenor
CXN (Telekom.de)" "Roaming" b true "Ethernet" a{sv} 4 "Method" s "auto"
"Interface" s "wwan0" "Address" s "FA:96:11:12:13:14" "MTU" q 1500 "IPv4" a{sv}
4 "Method" s "dhcp" "Address" s "100.64.8.49" "Netmask" s "255.0.0.0" "Gateway"
s "100.64.8.50" "IPv4.Configuration" a{sv} 1 "Method" s "dhcp" "IPv6" a{sv} 0
"IPv6.Configuration" a{sv} 1 "Method" s "off" "Nameservers" as 2 "172.30.0.53"
"172.30.0.153" "Nameservers.Configuration" as 0 "Timeservers" as 0
"Timeservers.Configuration" as 0 "Domains" as 1 "IFX_CDCECM"
"Domains.Configuration" as 0 "Proxy" a{sv} 0 "Proxy.Configuration" a{sv} 0
"Provider" a{sv} 0
So..only one service which isn't wifi, but wifi tech still connected? Let's
see..
In wifi.c:interface_state() line 2546 or so it says that we assume that reason
1 is because we are blocked. We also seem to assume that this is thrown when we
are connecting, so we call connman_network_set_error(network,
CONNMAN_NETWORK_ERROR_BLOCKED). This trickles down into
service.c:service_indicate_state() line 5795 or so where
connman_agent_report_error() is called. In my case I do have an agent
registered, so that call will return -EINPROGRESS which will make
service_indicate_state() to return then and there, calling SOME of the
functions below on completion, but not __connman_notifier_disconnect(), which
would ultimately have triggered the technology change to connected=false.
I don't know if this should be fixed in service_indicate_state() so that we
would make sure that __connman_notifier_disconnect() is called, or in wifi.c to
add something like this:
diff --git a/plugins/wifi.c b/plugins/wifi.c
index f8c22be3..27dfb07c 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2546,8 +2546,9 @@ static void interface_state(GSupplicantInterface
*interface)
/* Let's assume it's because we got blocked */
case 6: /* Class 2 frame received from nonauthenticated STA */
- connman_network_set_error(network,
- CONNMAN_NETWORK_ERROR_BLOCKED);
+ if (!wifi->connected)
+ connman_network_set_error(network,
+
CONNMAN_NETWORK_ERROR_BLOCKED);
break;
default:
so that we just follow the normal disconnect flow if we are connected. But the
service.c thing seems like a bug to me anyway. I can implement a fix and have
it thoroughly tested, but need your input on what would be the best fix.
--
Thanks,
Henrik Persson
Verisure Innovation AB
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 41, Issue 8
**************************************
