Bug 3202 - [FRI2]No WiFi section available in connman
Summary: [FRI2]No WiFi section available in connman
Status: VERIFIED FIXED
Alias: None
Product: BSPs
Classification: Build System, Metadata & Runtime
Component: bsps-meta-intel (show other bugs)
Version: 1.3
Hardware: Other Multiple
: High normal
Target Milestone: 1.3 M5
Assignee: Ross Burton
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2012-10-01 13:26 UTC by Alexandru Palalau
Modified: 2012-10-03 16:03 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandru Palalau 2012-10-01 13:26:29 UTC
Connman does not present WiFi connection settings.
There is no WiFi section available within the Connman interface although the iwlwifi module is properly loaded.
Commit ID: 718eb85806e080d0b165344b272e531ef19421eb
Dmesg does not provide any error message regarding the mentioned behavior.
Comment 1 Darren Hart 2012-10-01 14:17:00 UTC
Please provide the complete build config from output of bitbake. We need to include at least the commit ID of all the layers involved (poky and meta-intel here). Is this fri2 or fri2-noemgd? Does dmesg list anything about the iwlwifi driver? Does lspci list the wireless card? Does your device have the wireless card in it?
Comment 2 Darren Hart 2012-10-01 14:17:14 UTC
.
Comment 3 Alexandru Palalau 2012-10-01 19:31:18 UTC
This came out at the Fullpass testing of the FRI2 (not fri2-noemgd).
The image was downloaded from autobuilder03. Complete link below:
http://autobuilder03.jf.intel.com/pub/nightly-meta-intel/20120926-1/machines/fri2/
Image type: core-image-sato-sdk
dmesg does not provide any error information regarding iwlwifi module.
The wlan card is visible and can be managed via ifconfig/iwconfig.
Comment 4 Alexandru Palalau 2012-10-01 19:47:13 UTC
.
Comment 5 Darren Hart 2012-10-01 20:01:47 UTC
If you can manage the card with iwconfig, then this sounds like a connman bug rather than an FRI2 BSP bug. Do you observe this behavior on any other BSP? Adding Ross for thoughts re. connman.

Why did you change status to WaitForUpstream? I've certainly used connman to configure the wireless network on the FRI2 in the past, so this isn't a missing feature.
Comment 6 Alexandru Palalau 2012-10-01 20:20:08 UTC
Other BSP's don't have wifi support. This is the reason why I added it as a FRI2 bug as it can be reproduced only on this platform. I thought that maybe something changed in connman, as this feature was successfully implemented in earlyer builds.
Tomorrow, I'll try to build an image using the same poky commit and the latest meta-intel commit, and check if the behavior is still encountered.
Thanks!
Comment 7 Alexandru Palalau 2012-10-02 13:47:03 UTC
Just built a core-image-sato-sdk image for the FRI2 under the 1.3_M5 branch and the behavior regarding connman is still being encountered.
Comment 8 Darren Hart 2012-10-02 15:21:47 UTC
I'm going to try and verify this behavior, but we need to have the wifi config working.
Comment 9 Darren Hart 2012-10-02 20:32:50 UTC
I've verified the DISTRO_FEATURES includes "wifi" for the fri2 build from master. I've checked the object files for wifi symbols and the config logs for connman-gnome and connman, both suggest wifi was configured in and built.

$ nm properties/connman-properties | grep wifi
0804e150 T add_wifi_service
0804dde0 T add_wifi_switch_button
0804d930 t update_wifi_ipv4

$ nm src/connmand | grep wifi
080ddd00 d __connman_builtin_wifi
0807b240 T connman_network_get_wifi_channel
0807b1e0 T connman_network_set_wifi_channel
080e3714 b option_wifi
08062320 t throw_wifi_scan.constprop.18
08061ab0 t wifi_disable
08061380 t wifi_enable
08060660 t wifi_exit
08062120 t wifi_init
08061540 t wifi_newlink
080ddd60 d wifi_ng_driver
08061440 t wifi_probe
08061330 t wifi_regdom_callback
08061bb0 t wifi_remove
08062430 t wifi_scan
08063760 t wifi_scan_fast
08062ff0 t wifi_scan_hidden
08061290 t wifi_set_regdom
080e3650 b wifi_technology


connman config.log:

  $ /build/poky/master/fri2_rNSzE8/tmp/work/core2-poky-linux/connman-1.4-r17.0/git/configure --build=x86_64-linux --host=i586-poky-linux --target=i586-poky-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/build/poky/master/fri2_rNSzE8/tmp/sysroots/fri2 ac_cv_path_WPASUPPLICANT=/usr/sbin/wpa_supplicant ac_cv_path_PPPD=/usr/sbin/pppd --enable-debug --enable-threads --enable-loopback --enable-ethernet --enable-wifi --enable-tist --enable-bluetooth --enable-tist --enable-tools --enable-test --disable-polkit --disable-client --enable-fake --disable-gtk-doc --disable-gtk-doc-html --disable-gtk-doc-pdf

(note the --enable-wifi)

However, it later contains:

WIFI_FALSE='#'
WIFI_TRUE=''

It isn't clear to me what that syntax is meant to imply.


From dmesg it is clear the iwlwifi device exists:

root@fri2:~# dmesg | grep iwlwifi
iwlwifi 0000:01:00.0: enabling device (0000 -> 0002)
iwlwifi 0000:01:00.0: pci_resource_len = 0x00002000
iwlwifi 0000:01:00.0: pci_resource_base = f94f0000
iwlwifi 0000:01:00.0: HW Revision ID = 0x34
iwlwifi 0000:01:00.0: irq 47 for MSI/MSI-X
iwlwifi 0000:01:00.0: loaded firmware version 17.168.5.3 build 42301
iwlwifi 0000:01:00.0: CONFIG_IWLWIFI_DEBUG disabled
iwlwifi 0000:01:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
iwlwifi 0000:01:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
iwlwifi 0000:01:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
iwlwifi 0000:01:00.0: CONFIG_IWLWIFI_P2P disabled
iwlwifi 0000:01:00.0: Detected Intel(R) Centrino(R) Advanced-N 6205 AGN, REV=0xB0
iwlwifi 0000:01:00.0: L1 Disabled; Enabling L0S
iwlwifi 0000:01:00.0: device EEPROM VER=0x715, CALIB=0x6
iwlwifi 0000:01:00.0: Device SKU: 0x1F0
iwlwifi 0000:01:00.0: Valid Tx ant: 0x3, Valid Rx ant: 0x3
iwlwifi 0000:01:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels

And lspci lists:
01:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34)

So from what I can tell, all the configuration bits are correct and in place in the image.
Comment 10 Ross Burton 2012-10-02 21:19:35 UTC
Install connman-tools (or is it -tests?), that installs some utilities you can use to dig around connman's view of the universe.

Another good tip is to kill connmand, and then run it with (iirc) --debug --no-daemon. You'll get pages of logs but you might be able to see why it doesn't show wifi.
Comment 11 Darren Hart 2012-10-02 21:48:08 UTC
I just built with both connman-tools and connman-tests :-)

connman list-services only lists the ethernet:

root@fri2:/usr/lib/connman/test# ./list-services 
[ ethernet_00b3386ee31d_cable ]
    IPv6.Configuration = { Method=auto Privacy=disabled }
    AutoConnect = true
    Name = Wired
    Nameservers = [ 192.168.1.1 ]
    Provider = { }
    Favorite = true
    Domains.Configuration = [ ]
    Timeservers.Configuration = [ ]
    State = online
    Proxy = { Method=direct }
    Nameservers.Configuration = [ ]
    IPv4 = { Method=dhcp Gateway=192.168.1.1 }
    Timeservers = [ 192.168.1.1 ]
    IPv6 = { }
    Domains = [ local ]
    Ethernet = { Interface=eth0 MTU=1500 Method=auto Address=00:B3:38:6E:E3:1D }
    Security = [ ]
    Proxy.Configuration = { }
    Type = ethernet
    Immutable = false
    IPv4.Configuration = { Method=dhcp }

Running connmand as:

connmand -d DEBUG -n -i wlan0 -i eth0

Results in one interesting line of output:

Adding interface wlan0 [ wifi ]
Ignoring interface wlan0 (filtered)


Interestingly, the interface doesn't list any accesspoints, which is rather concerning:

root@fri2:/usr/lib/connman/test# iwlist wlan0 ap
wlan0     Interface doesn't have a list of Peers/Access-Points
Comment 12 Darren Hart 2012-10-02 21:53:50 UTC
Possibly relevant:

http://lists.linuxwimax.org/pipermail/connman/2011-July/005373.html
Comment 13 Darren Hart 2012-10-02 22:02:48 UTC
OK, I got wireless working.

# killall connmand
# wpa_supplicant -Dwext -iwlan0 -dd -u

New terminal

# export CONNMAN_SUPPLICANT_DEBUG=1
# connmand --debug=0xffffffff -i wlan0 -p wifi -n -W wext

With that I was able to open the connman-properties from the applet and enable, scan, and associate from the Wireless Networks tab in the UI.

Off to look at how this differs from the automated command lines...
Comment 14 Darren Hart 2012-10-02 22:04:14 UTC
(In reply to comment #12)
> Possibly relevant:
> 
> http://lists.linuxwimax.org/pipermail/connman/2011-July/005373.html

wpa_supplicant -dd reports that we are using the new dbus thingie...
Comment 15 Darren Hart 2012-10-02 22:26:32 UTC
OK, apparently just starting wpa_supplicant from the command line after boot fixes things:

# wpa_supplicant -u

Then accessing the connman-properties shows the wireless networks.

Did wpa_supplicant used to be started manually? Should connman be starting it on it's own? Do we need to specify that we want it to start with the wifi plugin and so it can start wpa_supplicant? If anyone knows the context, I'd appreciate it.

/me goes off to figure out what changed....
Comment 16 Darren Hart 2012-10-02 23:25:23 UTC
OK, turns out the problem goes away by reverting:

4f2da78be65eba3760142144ad7ba6abef8408f4
Author: Cristian Iorga <cristian.iorga@intel.com>
Date:   Wed Jul 18 15:36:28 2012 +0300

    wpa-supplicant: upgrade to 1.0


That's really unfortunate. Trying to see if there may have been some unintended change that came along with the update.
Comment 17 Darren Hart 2012-10-02 23:59:30 UTC
From what I can tell, there is no difference between the associated meta-data from the 0.7 recipe to the 1.0 recipe of wpa-supplicant. The breakage appears to be entirely source related.

A few things that come to mind:

o Different dbus interface ?
o Different default -W driver ?
o Different default interfaces managed ?
o Perhaps something additional is required in the runtime conf file or the 
  compile-time .config file ?

Ross and Cristian, can you please have a look over my night-time to try and get this resolved ASAP?

Christian, what sort of testing was done prior to sending the upgrade to 1.0 patches? Did this work on some other system?
Comment 18 Darren Hart 2012-10-03 00:08:49 UTC
Hrm... something I haven't explored yet - the connman update to 1.4 on Aug 17. It's possible this broke the interface to wpa_supplicant 1.0 and that it worked with connman 1.3. That might be worth exploring as well.

commit 9e36b4f21b5b73dc75382258102cc1575886c88d
Author: Constantin Musca <constantinx.musca@intel.com>
Date:   Fri Aug 17 19:10:46 2012 +0300

    connman: upgrade to 1.4
    
    The removed patch is included in connman 1.4.
    
    (From OE-Core rev: a1f16a0f3a015628f3d2d02d980311537a3a2c00)
    
    Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
    Signed-off-by: Saul Wold <sgw@linux.intel.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

There are several wpa_supplicant related changes in the 1.4 release over the 1.3 release.
Comment 19 Ross Burton 2012-10-03 11:39:21 UTC
Root-caused, fixing now.
Comment 20 Ross Burton 2012-10-03 12:13:29 UTC
Patch to wpa-supplicant sent.
Comment 21 Ross Burton 2012-10-03 12:45:25 UTC
Fixed in oe-core 41388c3ae0f4d9cd07e1599fbe125123c20820f8.

(tested on atom-pc, symptoms identical)
Comment 22 Darren Hart 2012-10-03 16:03:40 UTC
Tested and verified on FRI2. Marking as such.