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. Re: Stale Wifi service and network not being destroyed?
(Henrik Persson)
4. Re: disconnect_code == 1 from wpa_s results in wrong state in
wifi tech (Henrik Persson)
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Mar 2019 16:41:53 +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:
<CABymUCNXk0JY--4QU-DesJ=5eamdjte1oq4odgdwnfgy1cb...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Daniel Wagner <[email protected]> ?2019?3?7??? ??4:07???
>
> 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?
Both boards have QCA chip and share the same driver. Kernel version is
4.14.103. There
is some NXP patches based on 4.14.103 commit. But I do not think this
issue is due to kernel
or driver issue because iwlist command works well when connmanctl has issue.
I did not finish porting iwd to my yocto platform yet due to ell
version issue. But I just find that WiFi works OK on boot up if I
specify a settings file instead of depends on connman to generate it.
Do you have any idea?
+[global]
+OfflineMode=false
+
+[WiFi]
+Enable=true
+Tethering=false
+
+[Bluetooth]
+Enable=true
+Tethering=false
+
+[Wired]
+Enable=true
+Tethering=false
Jun
>
> 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: 2
Date: Mon, 11 Mar 2019 09:53:37 +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; format=flowed
> Both boards have QCA chip and share the same driver. Kernel version is
> 4.14.103.
So there is no surprise. They should behave the same.
> There is some NXP patches based on 4.14.103 commit. But I do not think this
> issue is due to kernel or driver issue because iwlist command works well when
> connmanctl has issue.
You can't compare iwlist with connmanctrl directly. iwlist works
directly on the Kernel APIs. You see what the kernel reports to
userland. ConnMan relies on wpa_supplicant to work correctly.
> I did not finish porting iwd to my yocto platform yet due to ell
> version issue.
I see you have Yocto fun as well :)
> But I just find that WiFi works OK on boot up if I
> specify a settings file instead of depends on connman to generate it.
> Do you have any idea?
If you start with an fresh installation, all technologies are disabled
by default (except ethernet).
> +[global]
> +OfflineMode=false
> +
> +[WiFi]
> +Enable=true
> +Tethering=false
> +
> +[Bluetooth]
> +Enable=true
> +Tethering=false
> +
> +[Wired]
> +Enable=true
> +Tethering=false
This enables all technologies, which is the same as calling 'connmanctl
enable wifi' after ConnMan has started.
------------------------------
Message: 3
Date: Mon, 11 Mar 2019 12:14:12 +0000
From: Henrik Persson <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Stale Wifi service and network not being destroyed?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
On 2019-03-10 19:53, Daniel Wagner wrote:
>> network->{driver,device} being NULL explains why -EIO is returned. I'm
>> thinking
>> that should not happen. I also found another connman_network when digging
>> into what the supplicant interface was seeing, and that's not the same
>> network
>> that the service holds a reference to..
>
> network->driver is set to NULL in network_remove(). I don't thin
> network_probe() is involved in your scenario. That would indicate that
> wpa_s decided to remove the network.
Yeah, and then added again at some later point. But the service was
never updated. I'm trying to debug another strange behavior that I
haven't reported yet, where I get in a state when trying to connect to a
AP with a hidden SSID and I always get -EIO on that connection attempt,
unless I wait for a few (milli)seconds before calling Connect over DBus
after the Services changed dbus notification arrives. I think that it
might be a race between the service getting updated once, triggering my
connect()-attempt and then being updated again which is blocked in
update_from_network() since we're connecting. Adding a timer and just
waiting a bit makes everything work again, so.. I guess the same thing
might happen here.
It feels strange that a service with network->driver set to null is
still returned in the list, and obviously still has a refcount..
>> Any pointers, suggestions, comments, etc that could either tell me that
>> I'm doing something wrong interacting with connman, or where to look
>> further?
>
> I think trying to get hold on the logs would be a good starting point,
> so the connman log and the wpa_supplicant log. Furthermore, set the
> CONNMAN_SUPPLICANT_DEBUG environment variable. That should give you
> what ConnMan thinks wpa_supplicant is doing.
Sure. I'm enabling debug and will try to enable the supplicant debug as
well. Good tip.
> BTW, which version of wpa_s are you using?
# wpa_supplicant -v
wpa_supplicant v2.6
Which is the one in yocto which seems to be pretty much 2.6 with some
patches for the KRACK attack. I could try getting 2.7 in there..
>> I'm on connman 1.35 btw because of reasons, but I didn't find anything
>> in the connman history since that point that should have fixed this. But
>> I'm gladly proven wrong.
>
> I suggest to give the current HEAD a try, we never know :)
I've now moved up to 1.36 at least. Should I feel brave enough to push
HEAD to a few thousand of our customers? :)
--
Henrik Persson
Verisure Innovation AB
------------------------------
Message: 4
Date: Mon, 11 Mar 2019 16:37:27 +0000
From: Henrik Persson <[email protected]>
To: Daniel Wagner <[email protected]>
Cc: connman <[email protected]>, Olof Winge
<[email protected]>
Subject: Re: disconnect_code == 1 from wpa_s results in wrong state in
wifi tech
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
On 2019-03-10 19:39, Daniel Wagner wrote:
>> 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.
>
>
> Okay, so we leave service_indicate_state() to early and get the state
> machine into inconsistent state. I digged a bit through the history
> and I didn't find any good explanation why we return early.
>
> I suppose we should do something like (completly untested):
[...]
> connman_agent_report_error() will do a log entry if something goes
> wrong. So we don't have to log it here. So could silenty go ahead and
> update the state machine.
The patch applied, I'll test it and see if it improves things. That
disconnect reason doesn't happen very often though, so might take a
while.. It doesn't seem to break anything in the happy-flow-case so
that's a good start. :)
--
Henrik
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 41, Issue 12
***************************************
