3202 2012-10-01 13:26:29 +0000 [FRI2]No WiFi section available in connman 2012-10-03 16:03:40 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-meta-intel 1.3 Other Multiple VERIFIED FIXED High normal 1.3 M5 1 alexandrux.palalau ross.burton cristian.iorga dvhart ross.burton tom.zanussi --- --- --- oldest_to_newest 25991 0 alexandrux.palalau 2012-10-01 13:26:29 +0000 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. 25994 1 dvhart 2012-10-01 14:17:00 +0000 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? 25995 2 dvhart 2012-10-01 14:17:14 +0000 . 26002 3 alexandrux.palalau 2012-10-01 19:31:18 +0000 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. 26004 4 alexandrux.palalau 2012-10-01 19:47:13 +0000 . 26006 5 dvhart 2012-10-01 20:01:47 +0000 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. 26007 6 alexandrux.palalau 2012-10-01 20:20:08 +0000 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! 26037 7 alexandrux.palalau 2012-10-02 13:47:03 +0000 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. 26046 8 dvhart 2012-10-02 15:21:47 +0000 I'm going to try and verify this behavior, but we need to have the wifi config working. 26074 9 dvhart 2012-10-02 20:32:50 +0000 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. 26077 10 ross.burton 2012-10-02 21:19:35 +0000 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. 26079 11 dvhart 2012-10-02 21:48:08 +0000 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 26080 12 dvhart 2012-10-02 21:53:50 +0000 Possibly relevant: http://lists.linuxwimax.org/pipermail/connman/2011-July/005373.html 26082 13 dvhart 2012-10-02 22:02:48 +0000 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... 26083 14 dvhart 2012-10-02 22:04:14 +0000 (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... 26084 15 dvhart 2012-10-02 22:26:32 +0000 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.... 26086 16 dvhart 2012-10-02 23:25:23 +0000 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. 26087 17 dvhart 2012-10-02 23:59:30 +0000 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? 26088 18 dvhart 2012-10-03 00:08:49 +0000 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. 26111 19 ross.burton 2012-10-03 11:39:21 +0000 Root-caused, fixing now. 26118 20 ross.burton 2012-10-03 12:13:29 +0000 Patch to wpa-supplicant sent. 26123 21 ross.burton 2012-10-03 12:45:25 +0000 Fixed in oe-core 41388c3ae0f4d9cd07e1599fbe125123c20820f8. (tested on atom-pc, symptoms identical) 26153 22 dvhart 2012-10-03 16:03:40 +0000 Tested and verified on FRI2. Marking as such.