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.
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?
.
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.
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.
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!
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.
I'm going to try and verify this behavior, but we need to have the wifi config working.
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.
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.
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
Possibly relevant: http://lists.linuxwimax.org/pipermail/connman/2011-July/005373.html
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...
(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...
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....
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.
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?
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.
Root-caused, fixing now.
Patch to wpa-supplicant sent.
Fixed in oe-core 41388c3ae0f4d9cd07e1599fbe125123c20820f8. (tested on atom-pc, symptoms identical)
Tested and verified on FRI2. Marking as such.