Hi Gentoo team, about a year ago I bought a SL510 Thinkpad and I have a strange wifi problem with it. Basically, it seems like dhcpcd during boot time fails because the wifi driver only initializes after it has been reloaded manually. So right after boot it looks like this: hal9001 ~ # ifconfig eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 metric 1 ether 60:eb:69:7e:91:c5 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 base 0x4000 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 metric 1 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Lokale Schleife) RX packets 48 bytes 4492 (4.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 48 bytes 4492 (4.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Then I always have to do: hal9001 ~ # /etc/init.d/net.wlan0 restart ; dhcpcd wlan0 * Bringing up interface wlan0 * Starting wpa_supplicant on wlan0 ... [ ok ] * Starting wpa_cli on wlan0 ... [ ok ] * Backgrounding ... ... * WARNING: net.wlan0 has started, but is inactive dhcpcd[3371]: version 5.2.12 starting dhcpcd[3371]: wlan0: waiting for carrier dhcpcd[3371]: wlan0: carrier acquired dhcpcd[3371]: wlan0: rebinding lease of 192.168.2.101 dhcpcd[3371]: wlan0: acknowledged 192.168.2.101 from 192.168.2.1 dhcpcd[3371]: wlan0: checking for 192.168.2.101 dhcpcd[3371]: wlan0: leased 192.168.2.101 for 345600 seconds dhcpcd[3371]: forked to background, child pid 3502 And then it looks like this: hal9001 ~ # ifconfig eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 metric 1 ether 60:eb:69:7e:91:c5 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 base 0x4000 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 metric 1 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 0 (Lokale Schleife) RX packets 48 bytes 4492 (4.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 48 bytes 4492 (4.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1 inet 192.168.2.101 netmask 255.255.255.0 broadcast 192.168.2.255 inet6 fe80::226:c7ff:fe70:c9c0 prefixlen 64 scopeid 0x20<link> ether 00:26:c7:70:c9:c0 txqueuelen 1000 (Ethernet) RX packets 7 bytes 594 (594.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 10 bytes 1074 (1.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 I have tried to sit it out but it is kind of a nuisance since lots of boottime scripts access network. Time setting, printer initialization, network shares and so on. So currently I have to redo all this manually every time I boot and I can't get the wifi to work unless I manually restart the interface and run dhcpcd again. Is there any way to fix this? I'm not sure what information I can provide. This problem has been there since I installed the system, which must have been linux 2.6.25 or earlier and it persists till now (3.1.2) I will attach my .config. Here is what dmesg says about it: [ 8.725836] Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:d [ 8.725840] Copyright(c) 2003-2011 Intel Corporation [ 8.725922] iwlagn 0000:05:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 8.725931] iwlagn 0000:05:00.0: setting latency timer to 64 [ 8.725966] iwlagn 0000:05:00.0: pci_resource_len = 0x00002000 [ 8.725970] iwlagn 0000:05:00.0: pci_resource_base = ffffc9001097c000 [ 8.725972] iwlagn 0000:05:00.0: HW Revision ID = 0x0 [ 8.725976] iwlagn 0000:05:00.0: pci_enable_msi failed(0Xffffffff) [ 8.726040] iwlagn 0000:05:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C [ 8.726089] iwlagn 0000:05:00.0: L1 Disabled; Enabling L0S [ 8.732149] iwlagn 0000:05:00.0: RF_KILL bit toggled to enable radio. [ 8.745706] iwlagn 0000:05:00.0: device EEPROM VER=0x15d, CALIB=0x6 [ 8.745709] iwlagn 0000:05:00.0: Device SKU: 0X50 [ 8.745711] iwlagn 0000:05:00.0: Valid Tx ant: 0X1, Valid Rx ant: 0X3 [ 8.745812] iwlagn 0000:05:00.0: Tunable channels: 13 802.11bg, 0 802.11a channels [ 8.923229] iwlagn 0000:05:00.0: loaded firmware version 39.31.5.1 build 35138 Looks normal to me. I have the firmware and everything installed and again, after manually restarting everthing after boot it works fine but it's getting very tedious and some subsystems that depend on it don't work at all properly. For instance ifplugd which keeps thinking I don't have wifi. Here's what the kernel log reveals in the time I do the manual jumpstart: Nov 26 13:49:01 hal9001 kernel: [ 655.738798] iwlagn 0000:05:00.0: L1 Disabled; Enabling L0S Nov 26 13:49:01 hal9001 kernel: [ 655.793403] iwlagn 0000:05:00.0: L1 Disabled; Enabling L0S Nov 26 13:49:01 hal9001 kernel: [ 655.846271] ADDRCONF(NETDEV_UP): wlan0: link is not ready Nov 26 13:49:01 hal9001 start-stop-daemon: pam_unix(start-stop-daemon:session): session opened for user nobody by sm(uid=0) Nov 26 13:49:01 hal9001 start-stop-daemon: pam_unix(start-stop-daemon:session): session opened for user nobody by sm(uid=0) Nov 26 13:49:01 hal9001 /etc/init.d/net.wlan0[3283]: WARNING: net.wlan0 has started, but is inactive Nov 26 13:49:01 hal9001 dhcpcd[3371]: version 5.2.12 starting Nov 26 13:49:02 hal9001 dhcpcd[3371]: wlan0: waiting for carrier Nov 26 13:49:02 hal9001 kernel: [ 656.620036] wlan0: authenticate with 00:12:bf:c9:d1:62 (try 1) Nov 26 13:49:02 hal9001 kernel: [ 656.621632] wlan0: authenticated Nov 26 13:49:02 hal9001 kernel: [ 656.621941] wlan0: associate with 00:12:bf:c9:d1:62 (try 1) Nov 26 13:49:02 hal9001 kernel: [ 656.624164] wlan0: RX AssocResp from 00:12:bf:c9:d1:62 (capab=0x471 status=0 aid=2) Nov 26 13:49:02 hal9001 kernel: [ 656.624167] wlan0: associated Nov 26 13:49:02 hal9001 kernel: [ 656.627929] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Nov 26 13:49:02 hal9001 dhcpcd[3371]: wlan0: carrier acquired Nov 26 13:49:02 hal9001 wpa_cli: interface wlan0 CONNECTED Nov 26 13:49:02 hal9001 dhcpcd[3371]: wlan0: rebinding lease of 192.168.2.101 Nov 26 13:49:02 hal9001 /etc/init.d/net.wlan0[3466]: You are using a bash array for config_wlan0. Nov 26 13:49:02 hal9001 /etc/init.d/net.wlan0[3467]: This feature will be removed in the future. Nov 26 13:49:02 hal9001 /etc/init.d/net.wlan0[3468]: Please see net.example for the correct format for config_wlan0. Nov 26 13:49:02 hal9001 dhcpcd[3479]: dumplease requires an interface Nov 26 13:49:02 hal9001 /etc/init.d/net.wlan0[3393]: ERROR: net.wlan0 failed to start Nov 26 13:49:02 hal9001 wpa_cli: executing '/etc/init.d/net.wlan0 --quiet start' failed Nov 26 13:49:02 hal9001 dhcpcd[3371]: wlan0: acknowledged 192.168.2.101 from 192.168.2.1 Nov 26 13:49:02 hal9001 dhcpcd[3371]: wlan0: checking for 192.168.2.101 Nov 26 13:49:07 hal9001 dhcpcd[3371]: wlan0: leased 192.168.2.101 for 345600 seconds Nov 26 13:49:07 hal9001 dhcpcd[3371]: forked to background, child pid 3502 Nov 26 13:49:13 hal9001 kernel: [ 667.602026] wlan0: no IPv6 routers present It does say link not ready but if this is the reason for the inital fault I do not know. Please let me know if I can provide further information. Cheers, Stephan
Created attachment 293819 [details] kernel config
Doesn't look like a kernel/driver problem if the "manual start" works fine. Which version of net-misc/dhcpcd is that? In other words, please post your `emerge --info net-misc/dhcpcd' output too.
OK, here's the requested information. I do however not really believe that this is the cause. First of all, the bug has been there for almost a year and during that time the system settings have changed a great many times. Second, I have tried different dhcp clients in order to solve this since I also believed it must have been it. But alas, it wasn't. Here's also my network config in case it matters. The dhcpd options below are actually residues of my efforts to solve it and I never changed them back. hal9001 ~ # cat /etc/conf.d/net dns_domain_lo=( "localdomain" ) modules=( "dhcpcd" ) modules=( "ifconfig" ) config_eth0=("dhcp") config_wlan0=("dhcp") modules=( "wpa_supplicant" ) wpa_supplicant_wlan0="-Dwext" wpa_timeout_wlan0=60 #ifplugd_eth0="..." dhcpcd_wlan0="-h -E -d -U wlan0" modules_wlan0=( "!plug" ) hal9001 ~ # emerge --info net-misc/dhcpcd Portage 2.1.10.39 (default/linux/amd64/10.0/desktop/kde, gcc-4.5.3, glibc-2.14.1-r1, 3.1.3-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.1.3-gentoo-x86_64-Pentium-R-_Dual-Core_CPU_T4500_@_2.30GHz-with-gentoo-2.1 Timestamp of tree: Wed, 30 Nov 2011 17:00:01 +0000 ccache version 3.1.6 [enabled] app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.2-r3, 3.2.2 dev-util/ccache: 3.1.6 dev-util/cmake: 2.8.6-r4 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.11.1-r1 sys-devel/binutils: 2.22 sys-devel/gcc: 4.5.3-r1 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.14.1-r1 Repositories: gentoo ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -mtune=native -O3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -mtune=native -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs ccache distlocks ebuild-locks fixlafiles metadata-transfer news parallel-fetch protect-owned sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo rsync://ftp.join.uni-muenster.de/gentoo/ ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/ rsync://ftp-stud.hs-esslingen.de/gentoo/" LANG="de_DE.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="64bit X a52 aac acl acpi akonadi alsa amd64 apng assistant audio audiofile bash-completion battery berkdb binary-drivers bluetooth boost branding bzip2 cairo cdda cdr cli cmake consolekit cracklib crypt cups curl cxx dbus declarative desktopglobe development dhcpcd dri dts dvd dvdr eix emboss encode eselect examples exif fam firefox firefox3 flac flash fortran fuse gcj gd gdbm gdu gif git glibc-omitfp gmp gnutls google gpac gpg gpm gstreamer gtk guile gzip hpcups html http i18n iconv icu id3 id3tag imagemagick innodb inotify int64 introspection iphone ipv6 jabber java jpeg jpeg2k kate kde kipi konqueror kontact laptop lastfm lastfmradio lcms ldap libnotify libxml2 logrotate lyrics lzma mad madwifi matroska minizip mmx mmxext mng modules mongodb mp3 mp4 mpeg mplayer mudflap multilib multimedia musepack music musicbrainz mysql ncurses net netpbm networking nicintel_spi nicrealtek nls nptl nptlonly nspluginwrapper nss ntfs offensive ogg openexr opengl openmp openssl openstreetmap pam pango pcre pdf phonon php plasma plugins png policykit postgres ppds pppd prelink python python-bindings python3 qt-faststart qt-webkit qt3support qt4 rar raw readline ruby ruby-bindings samba sdl secure-delete semantic semantic-desktop session sieve sound spell sql sqlite sqlite3 sse sse2 ssl ssse3 startup-notification subtitles sudo suid svg swat swig symlink sysfs syslog system-libs system-sqlite taglib tcpd tcpdump tcpreplay themes theora thinkpad threads threadsafe tiff tools transcode truetype tsmuxer udev unicode unix unlock-notify unzip upnp usb utils v4l vaapi valgrind video vim vim-pager vim-syntax vimeo virtuoso visualizer vlc vorbis wav webcam webkit webm wifi wiki win32 wineappdb wireshark wxwidgets x264 xcb xcomposite xine xinerama xml xorg xrandr xscreensaver xslt xulrunner xv xvid youtube zeroconf zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="vesa intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= net-misc/dhcpcd-5.2.12-r1 was built with the following: USE="(consolekit) (multilib) (policykit) zeroconf" CFLAGS="-march=native -ggdb -mtune=native -O3 -pipe" CXXFLAGS="-march=native -ggdb -mtune=native -O3 -pipe"
So you think it's rather some kind of slowness in the kernel driver after the connection is up? Does a `sleep 5' somewhere in an /etc/init.d/net.* script solve the issue?
Hi Jeroen, I just tried sleeping all over the place and it didn't work out. There's one thing however, that must be mentioned which I guess I didn't before. The script doesn't actually _try_ to start the interface. So when I do my manual starting, I see that: hal9001 ~ # /etc/init.d/net.wlan0 start ; dhcpcd wlan0;exit * Bringing up interface wlan0 * Starting wpa_supplicant on wlan0 ... [ ok ] * Starting wpa_cli on wlan0 ... [ ok ] * Backgrounding ... ... * WARNING: net.wlan0 has started, but is inactive dhcpcd[3079]: version 5.2.12 starting dhcpcd[3079]: wlan0: waiting for carrier dhcpcd[3079]: wlan0: carrier acquired dhcpcd[3079]: wlan0: rebinding lease of 192.168.178.26 dhcpcd[3079]: wlan0: acknowledged 192.168.178.26 from 192.168.178.1 dhcpcd[3079]: wlan0: checking for 192.168.178.26 dhcpcd[3079]: wlan0: leased 192.168.178.26 for 864000 seconds dhcpcd[3079]: forked to background, child pid 3188 But there's no such output during the boot process. Neither successfully nor with an error message. The start script doesn't appear to be running at all. I was under the impression it's ifplugd preventing it or a dependency of the script to some system internal value that is not fulfilled. Sorry I can't be too helpful but I am not very good at such start script things and I don't really understand which things those script actually can depend on. I know it can be loaded modules but the bug appears in both cases, iwlagn as a module or built into the kernel so I guess that's not it. I have just checked the kernel log again and maybe this gives a clue: Dec 4 12:07:14 hal9001 kernel: [ 8.622868] iwlagn 0000:05:00.0: loaded firmware version 39.31.5.1 build 35138 Dec 4 12:07:14 hal9001 kernel: [ 8.623278] Registered led device: phy0-led Dec 4 12:07:14 hal9001 kernel: [ 8.623359] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' ... usb stuff .... Dec 4 12:07:21 hal9001 kernel: [ 35.042146] r8169 0000:08:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168d-1.fw (-2) Dec 4 12:07:21 hal9001 kernel: [ 35.050301] r8169 0000:08:00.0: eth0: link down Dec 4 12:07:21 hal9001 kernel: [ 35.050560] ADDRCONF(NETDEV_UP): eth0: link is not ready See that? It looks like the _other_ NIC (rtl8168) is not shooting up properly due to missing firmware. And then: Dec 4 12:07:21 hal9001 ifplugd(eth0)[2343]: ifplugd 0.28 initializing. Dec 4 12:07:21 hal9001 ifplugd(eth0)[2343]: Using interface eth0/60:EB:69:7E:91:C5 with driver <r8169> (version: 2.3LK-NAPI) Dec 4 12:07:21 hal9001 ifplugd(eth0)[2343]: Using detection mode: SIOCETHTOOL Dec 4 12:07:21 hal9001 ifplugd(eth0)[2343]: Initialization complete, link beat not detected. Dec 4 12:07:21 hal9001 /etc/init.d/net.eth0[2268]: WARNING: net.eth0 has started, but is inactive Dec 4 12:07:21 hal9001 start-stop-daemon: pam_unix(start-stop-daemon:session): session opened for user nobody by (uid=0) Dec 4 12:07:22 hal9001 start-stop-daemon: pam_unix(start-stop-daemon:session): session opened for user nobody by (uid=0) Dec 4 12:07:24 hal9001 /etc/init.d/netmount[2410]: WARNING: netmount is scheduled to start when net.eth0 has started Dec 4 12:07:24 hal9001 /etc/init.d/ntp-client[2411]: WARNING: ntp-client is scheduled to start when net.eth0 has started Ifplugd gets stuck because the NIC is not started and it doesn't go to initializing the wifi link at all. This would explain it perhaps? I have just googled around and found this: http://www.gentoo-wiki.info/RTL8168 but this seems old and doesn't tell me where I could get this firmware. Maybe that's not really the issue but I have it in my guts that this may be an important clue. Does it make sense to you? Is there any way I could verify this? Cheers, Stephan
A little addition here: I just tried disabling eth0 completely and removed all it's drivers to make sure no script thinks it should be there but that didn't do the trick.
The interface works, but there is no network configuration =========================================================== Dec 6 07:24:34 gentoo-lxde dhcpcd[4464]: version 5.2.12 starting Dec 6 07:24:35 gentoo-lxde dhcpcd[4464]: eth0: broadcasting for a lease Dec 6 07:24:35 gentoo-lxde dhcpcd[4464]: eth0: offered 10.0.2.15 from 10.0.2.2 Dec 6 07:24:35 gentoo-lxde dhcpcd[4464]: eth0: acknowledged 10.0.2.15 from 10.0.2.2 Dec 6 07:24:35 gentoo-lxde dhcpcd[4464]: eth0: checking for 10.0.2.15 Dec 6 07:24:39 gentoo-lxde dhcpcd[4464]: eth0: leased 10.0.2.15 for 86400 seconds Dec 6 07:24:39 gentoo-lxde dhcpcd[4464]: forked to background, child pid 4500 Dec 6 07:24:44 gentoo-lxde dhcpcd[4503]: sending signal 1 to pid 4500 Dec 6 07:24:44 gentoo-lxde dhcpcd[4500]: received SIGHUP, releasing Dec 6 07:24:44 gentoo-lxde dhcpcd[4500]: eth0: releasing lease of 10.0.2.15 Dec 6 07:24:44 gentoo-lxde dhcpcd[4503]: waiting for pid 4500 to exit Dec 6 07:24:44 gentoo-lxde dhcpcd[4500]: eth0: removing interface Dec 6 07:24:44 gentoo-lxde kernel: 8139cp 0000:00:03.0: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 =================================================================== 00:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20) =================================================================== Portage 2.2.0_alpha79 (default/linux/x86/10.0, gcc-4.6.2, glibc-2.14.1-r1, 3.1.4-gentoo i686) ================================================================= System uname: Linux-3.1.4-gentoo-i686-QEMU_Virtual_CPU_version_0.15.1-with-gentoo-2.1 Timestamp of tree: Mon, 05 Dec 2011 16:00:01 +0000 ccache version 3.1.6 [enabled] app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.2-r3 dev-util/ccache: 3.1.6 dev-util/cmake: 2.8.6-r4 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1 sys-apps/openrc: 0.9.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.9.6-r3, 1.11.1-r1 sys-devel/binutils: 2.22 sys-devel/gcc: 4.6.2 sys-devel/gcc-config: 1.5-r2 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.14.1-r1 Repositories: gentoo overlays-oschtan Installed sets: @lxde-full ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA skype-eula dlj-1.1 AdobeFlash-10.1 google-chrome Oracle-BCLA-JavaSE google-talkplugin" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/themes/oxygen-gtk/gtk-2.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs ccache distlocks ebuild-locks fixlafiles news nodoc noinfo noman parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://linux.nsu.ru/gentoo-distfiles http://distfiles.gentoo.org" LANG="ru_RU.UTF-8" LC_ALL="" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="ru" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="Oracle-BCLA-JavaSE X a-like-o acpi action_modeswitch alsa apng berkdb bolddiag bzip2 cleartype cli consolekit cracklib cxx dbus disk-partition djvu dri dri2 dvd dvdr extras faad fbcondecor ffmpeg flac fortran ftp gallium gif glitz gpm gtk iconv id3tag jpeg libnotify llvm madwifi minimal mmx modules mp3 mudflap ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre policykit pppd readline remote ru-dv ru-i ru-k samba session sse sse2 sse3 ssl ssse3 svg sysfs tcpd theora truetype udev unicode vorbis vpx x86 xcb xorg xv zlib" ALSA_CARDS="hda-intel snd-intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev synaptics virtualbox" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="ru" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="virtualbox intel radeon nouveau cirrus" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #7) > The interface works, but there is no network configuration So what do mean by this? Are you having the same issue? Cheers, Stephan
Does this issue still occur with later kernels.
Sorry, I didn't see that last comment. To answer the question: yes, it does. I do not recall the first kernel that bug occured with but I guess it must have been 2.6.26 or something along those lines. Right now it's 3.3.1 and the bug is there as always. Cheers, Stephan
It's been five months, if this is still an issue with current versions, please reopen.
Hi Mike, the bug is still there. I have just tried it and there is no change in behaviour. I cannot reopen this though. For some strange reason the combobox below this comment box doesn't offer any choices but "confirmed" and "verified". I can do neither. Shouldn't it say "reopen" or "unconfirmed" or something? I take this as an invitation to not reopen ;-) Anyway, if you are interested, please reopen for accuracy's sake. Otherwise, I'm not so much affected anymore since I have taken the issue as a reason to put cable in my place and to move away from wifi. Stephan
By the way, is there a reason I cannot reopen this?
> It looks like the _other_ NIC (rtl8168) is not shooting up properly due to missing firmware. > ... > Ifplugd gets stuck because the NIC is not started and it doesn't go to initializing the wifi link at all. This would explain it perhaps? > ... > but this seems old and doesn't tell me where I could get this firmware. This sounds like a very possible cause. The kernel would tell you which firmware you'd need exactly through the dmesg log; so, for instance I have the 07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) so while I don't know how to directly figure out which one this would use, I know it's one of rtl8168d-1.fw rtl8168d-2.fw rtl8168e-1.fw rtl8168e-2.fw rtl8168e-3.fw rtl8168f-1.fw rtl8168f-2.fw rtl8168g-1.fw now you'd might wonder where to obtain these from, which means you'd need a way to figure out which package a file you don't have belongs to. You can do this with `emerge pfl && e-file rtl8168d-1.fw` (example firmware from that list), which reveals us: [I] sys-kernel/linux-firmware Available Versions: 20120125 20110818 20110731 20110709 20110604 20110601 20110429 20120924 20110311 20120909 99999999 20120816 20120719 20120708 20120615 20120502 20120219 Last Installed Ver: 20120924(Thu 04 Oct 2012 03:48:33 AM CEST) Matched Files: /lib/firmware/rtl_nic/rtl8168d-1.fw; It should be sufficient to `emerge sys-kernel/linux-firmware` to obtain the firmware, please test using this firmware to see if ifplugd behaves correctly and whether that solves the wlan0 problem.
Hi Tom, sadly, I have tried those combinations already. At the moment I didn't have linux-firmware installed but iwl-ucode1000 and iwl-ucode5000 which I thought to contain the firmware. Plus, I always use 'make install-firmware' when I install a kernel, which I think places those files too, doens't it? Anyway, I just removed those and replaced by linux-firmware again but it didn't help. What I do notice however is a change in the dmesg. It tells now: [ 9.303859] iwldvm: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:d [ 9.303862] iwldvm: Copyright(c) 2003-2012 Intel Corporation [ 9.303899] iwlwifi 0000:05:00.0: CONFIG_IWLWIFI_DEBUG enabled [ 9.303901] iwlwifi 0000:05:00.0: CONFIG_IWLWIFI_DEBUGFS disabled [ 9.303904] iwlwifi 0000:05:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled [ 9.303906] iwlwifi 0000:05:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE enabled [ 9.303908] iwlwifi 0000:05:00.0: CONFIG_IWLWIFI_P2P disabled [ 9.303911] iwlwifi 0000:05:00.0: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C [ 9.303969] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S [ 9.311332] iwlwifi 0000:05:00.0: RF_KILL bit toggled to enable radio. [ 9.323994] iwlwifi 0000:05:00.0: device EEPROM VER=0x15d, CALIB=0x6 [ 9.323997] iwlwifi 0000:05:00.0: Device SKU: 0x50 [ 9.323999] iwlwifi 0000:05:00.0: Valid Tx ant: 0x1, Valid Rx ant: 0x3 and ... [ 127.102363] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S [ 127.109775] iwlwifi 0000:05:00.0: Radio type=0x0-0x0-0x3 [ 127.156485] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S [ 127.163879] iwlwifi 0000:05:00.0: Radio type=0x0-0x0-0x3 [ 127.213813] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 128.004384] wlan0: authenticate with bc:05:43:16:b7:ef [ 128.013060] wlan0: send auth to bc:05:43:16:b7:ef (try 1/3) [ 128.018299] wlan0: authenticated [ 128.019052] wlan0: associate with bc:05:43:16:b7:ef (try 1/3) [ 128.040491] wlan0: RX AssocResp from bc:05:43:16:b7:ef (capab=0x431 status=0 aid=1) [ 128.042937] wlan0: associated [ 128.042960] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready looks more verbose than it used to. The symptoms however are still the same. The link is not there until I restart it. With all that being said however, I do realize that this bug is not one to go down easily. And with me having laid cable I only consider this a strange conundrum or a mild hassle when I'm out and need wifi. So there's no real need for a fix here unless one likes riddles. I just didn't want the bug to be set on NEEDINFO because I am willing to provide all info needed to solve the riddle ;-) Cheers, Stephan
And how about the other NIC? > It looks like the _other_ NIC (rtl8168) is not shooting up properly due to missing firmware. > ... > Ifplugd gets stuck because the NIC is not started and it doesn't go to initializing the wifi link at all. This would explain it perhaps? > ... > but this seems old and doesn't tell me where I could get this firmware. See my previous comment...
Well, I cannot see any such line in the dmesg anymore. It doesn't complain about missing firmware. Strangley, it's not telling anything about found firmware either, which I thought it would. I'll attach the current dmesg output. Maybe you can see something in it that I don't. Thanks, Stephan
Created attachment 327570 [details] current dmesg output with no complains about missing firmware.
[ 8.698329] iwlwifi 0000:05:00.0: pci_enable_msi failed(0Xffffffff) This line doesn't look good, although they continue initialization and there are people reporting it working despite that line if you search for it. http://article.gmane.org/gmane.linux.kernel/1225921/ I'm starting to wonder if this has anything to do with the kernel at all, it's as if it just doesn't automatically connect on boot. But on the other hand it might be waiting for something that the manual trigger might fix. Let's wait and see if someone else still has an idea on this...
> [ 0.000000] Linux version 3.6.2-gentoo (root@hal9001) (gcc version 4.6.3 (Gentoo 4.6.3 p1.3, pie-0.5.1) ) #1 SMP Fri Oct 26 20:59:27 CEST 2012 According to your dmesg you have last tried 3.6.2. Please try on testing arch using =sys-kernel/gentoo-sources-3.6.5 to see if this is still present in the latest available version, or even better woul be to attempt to get git-sources-3.7_rc3 to work, although that might break packages dependent on the kernel (although it's worth the breakage sometimes). If it breaks again there we should probably file this upstream, especially since that part of code looks somewhat unstable. I mean, there's even a TODO right there in the URL I linked: /* TODO: Move this away, not needed if not MSI */ /* enable rfkill interrupt: hw bug w/a */ Checking my git clone of linux-git, it appears that TODO is still in place _but_ the code around it has changed slightly recently which might impose that it will have a different behavior for you. The file involved was also moved in a pcie subdirectory. So really consider to attempt to try git-sources-3.7_rc3 if you can... Just for reference: Commit log touching the new file: http://bpaste.net/show/55675/ Commit log touching the older file: http://bpaste.net/show/55676/ Note how the first commits for the new file target late 3.6 and early 3.7.
Hi Tom, I have just tried the vanilla kernel tagged as v3.7-rc4. Same symptoms. I'll attach the dmesg output. It still contains the line you mentioned. I'm not quite sure about filing this upstream though. Too weird. Besides, one cannot be certain it really is the kernel. It could still be gentoo's start scripts, the firmware, some other influence that I do not know about or the very BIOS or even hardware. However, it's your call. If you think it's reasonable we can do it. What concerns me a bit is the fact that there hasn't been much attention to this one. The SL510 is a model that has been sold well and I would expect lots of people to run Linux on it. So I would expect at least a few more people to have the same problem. As this is apparently not the case it might be just the hardware being a bit off or maybe something went wrong during the installation that never got set straight. All long shots but not impossible. Cheers, Stephan
Created attachment 328482 [details] dmesg of vanilla v3.7-rc4
>--- my.dmesg.iwl 2012-11-05 23:09:22.037993988 +0100 >+++ your.dmesg.iwl 2012-11-05 23:09:19.692021964 +0100 >@@ -1,22 +1,19 @@ > iwlwifi: pci_resource_len = 0x00002000 >-iwlwifi: pci_resource_base = ffffc90000074000 >+iwlwifi: pci_resource_base = ffffc900116bc000 > iwlwifi: HW Revision ID = 0x0 >-iwlwifi: irq 47 for MSI/MSI-X >+iwlwifi: pci_enable_msi failed(0Xffffffff) >-iwlwifi: loaded firmware version 8.83.5.1 build 33692 >+iwlwifi: loaded firmware version 39.31.5.1 build 35138 >-iwldvm: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree: >+iwldvm: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:d > iwldvm: Copyright(c) 2003-2012 Intel Corporation >-iwlwifi: CONFIG_IWLWIFI_DEBUG disabled >+iwlwifi: CONFIG_IWLWIFI_DEBUG enabled > iwlwifi: CONFIG_IWLWIFI_DEBUGFS disabled > iwlwifi: CONFIG_IWLWIFI_DEVICE_TRACING disabled >-iwlwifi: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled >+iwlwifi: CONFIG_IWLWIFI_DEVICE_TESTMODE enabled > iwlwifi: CONFIG_IWLWIFI_P2P disabled >-iwlwifi: Detected Intel(R) WiFi Link 5100 AGN, REV=0x54 >+iwlwifi: Detected Intel(R) Centrino(R) Wireless-N 1000 BGN, REV=0x6C >-iwlwifi: L1 Disabled; Enabling L0S >+iwlwifi: L1 Enabled; Disabling L0S >+iwlwifi: RF_KILL bit toggled to enable radio. >-iwlwifi: device EEPROM VER=0x11f, CALIB=0x4 >+iwlwifi: device EEPROM VER=0x15d, CALIB=0x6 >-iwlwifi: Device SKU: 0xF0 >+iwlwifi: Device SKU: 0x50 >-iwlwifi: Valid Tx ant: 0x2, Valid Rx ant: 0x3 >+iwlwifi: Valid Tx ant: 0x1, Valid Rx ant: 0x3 > ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' >-iwlwifi: L1 Disabled; Enabling L0S >-iwlwifi: Radio type=0x1-0x2-0x0 >-iwlwifi: L1 Disabled; Enabling L0S >-iwlwifi: Radio type=0x1-0x2-0x0 The different resource base and MSI failure should not be bad. Your firmware is more recent so that's also okay. The in-tree:d indicates that you have debugging on. Your driver is in debug and test mode. Then I notice a huge difference (see ASPM info on these two states at [1]), yours put the drive in a power safe mode and needs to toggle a RF_KILL bit. I'm wondering whether this matters. Also later on, mine lists radio types which yours doesn't which probably indicates the absence of the radio as yours might not be able to come due to the power safe mode. Things to try: 1. See whether you can try a different firmware version. Perhaps you just have broken firmware? 2. Try to see whether this works without debug. Does that toggle CONFIG_IWLWIFI_DEVICE_TESTMODE? 3. Since you mentioned it could be anything, you could set up a minimal Gentoo in a chroot. Make sure you do compile a kernel from and for that chroot, then add a boot loader entry that boots from that kernel with your chroot as root) and attempt to see whether your iwlwifi works there such that this isn't affected by any misconfiguration. The chance that this exists is high as you have been using Gentoo for over a year and had ifplugd problems around this time. Does that chroot give the same problem? The chroot would suffice as a confirmation that it's not a problem with any configuration you have done and would limit the problem to either the baselayout or the kernel, and I doubt it has to do anything with the baselayout so if a chroot is broken it really is a bug worth reporting upstream. There haven't been any others reporting this as far as I can see, thus it's very plausible that you may have made a configuration mistake or the firmware is broken. [1]: https://en.wikipedia.org/wiki/Active_State_Power_Management
Hi Tom, I have gone trough your suggestions. I feel you have lost me a bit but I try to keep up. > Things to try: > 1. See whether you can try a different firmware version. Perhaps you > just have broken firmware? I have not explicitly tried that right now. However, given the age of the problem, I would assume that gentoo would have pulled in all sorts of versions that came in that time. Right now, it is this version: [I] sys-kernel/linux-firmware Available versions: 20120719 (~)20120816 (~)20120909 20120924 (~)20121030 **99999999 {{savedconfig}} Installed versions: 20121030(19:19:25 06.11.2012)(-savedconfig) Homepage: http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git Description: Linux firmware files and I also have this merged: [I] net-wireless/ipw2200-firmware Available versions: (2.2) (~)2.2 (2.3) (~)2.3 (0) (~)2.4 3.0 3.1 {{KERNEL="FreeBSD linux"}} I'm not sure though, if both are relevant. The way I understand the kernel install scripts, when I say make modules_install firmware_install install it copies in-kernel firmware to /lib, thereby replacing the firmware that comes with above packge, right? > 2. Try to see whether this works without debug. Does that toggle > CONFIG_IWLWIFI_DEVICE_TESTMODE? I have just tried to play around with those options. The way I remember, I have toggled debugging on when I first encountered this and it's still on. I have switched it off, to no avail and also tried to disabled that TESTMODE. To my surprise, it cannot be disabled. There's no such option in menuconfig and when I manually edit the file, disable the option and build a kernel, the option is magically switched back on. I have tried a lot of things and it looks like make oldconfig as well as make menuconfig turn TESTMODE on, whatever they find in the .config file. Very strange, since TESTMODE doesn't sound very stable to me. Maybe there's a bug here in the config system? Or maybe that's just the way they want it. > 3. Since you mentioned it could be anything, you could set up > a minimal Gentoo in a chroot. Make sure you do compile a kernel > from and for that chroot, then add a boot loader entry that > boots from that kernel with your chroot as root) OK, as much as I would love to dig in this deep, this is a bit over my head. I'm not sure how to do this. Besides, it would be against of one of my iron clad principles when it comes to computers: Never mess with your boot loader unless absolute urgently necessary. Once a bootloader works, I never touch it. Maybe I could minimal boot from a USB stick or something? That would be pretty much the same effect, right? As a side note, I just noticed something strange that may be related. I am currently playing around with lots of different VPN setups. Have settled for a openvpn from init scripts that are supposed to start right after eth0. This appears to work but when I look in the logs, only on the second attempt. OpenVPN tries to establish the connection, fails, waits a few secs and tries again. This time, it works. This doesn't affect me like this bug as I don't notice it as as user but it's network startup sequence related and sounds very familiar. Thought I'd mention it but it may not be related at all. Plz let me know what you think about the USB stick. Cheers, Stephan
> However, given the age of the problem, I would assume that gentoo would have pulled in all sorts of versions that came in that time. In a year time they would've indeed updated a few times. > thereby replacing the firmware that comes with above packge, right? Correct. > Never mess with your boot loader unless absolute urgently necessary. Once a bootloader works, I never touch it. There's nothing wrong with using backing up the configuration file your boot loader is using and trying a new one with an additional entry, you can always put back the older one. Perhaps even just `mount /boot && cp -R /boot /boot_backup`. That's all assuming you have a installation medium at your disposal from which you can mount your boot partition to correct the config in case you did something wrong in it. If not, the minimal USB installation would also be an approach to try. For chroot instructions, see http://wiki.gentoo.org/wiki/Chroot
It's been quiet around here and so I did a little more testing to get to the bottom of this. I have just tried a few other OSes to confirm it's not the hardware. First Windows7. It sort of came with the laptop and I never uninstalled it, although I never let it access the network either due to security concerns. So I finally let Windows into the internet and it used the wifi connection without any problems before and after I had to install a bazillion updates. So Windows was OK. Then I created a LiveUSB Stick with a recent Ubuntu on it. And Ubuntu too accessed the wifi card right from the start without any problems. Actually, I was quite impressed by the ease of use on how Ubuntu did this ;-) The kernel appeared to be a 3.5.0 with a few patches. The loaded firmware appeared to be a version very similar to mine. So I believe this rules out a hardware problem. And the kernel as well, since 3.5 had the same problem here as all kernels before. This leaves Gentoo's scripts and a configuration issue. I think I'm gonna try to create a live usb gentoo stick and see if that works. There's another thing that I noticed and that may be relevant. The init scripts for the card are configured to use dhcp. Now, dhcpcd is installed and works. But I always have to triger it manually, also in subsequent starts of the interface. When I have freshly booted, interface wlan0 is not there. Then I $ /etc/init.d/net.wlan0 restart which will create the interface but in order to use it I also have to: $ dhcpcd wlan0 Every time. Not just at the first restart. Now isn't that somewthing that's supposed to be handled by the init script as well? I would believe so. Here's my network config again as it looks now. sm@hal9001 ~ $ cat /etc/conf.d/net dns_domain_lo="localdomain" modules="dhcpcd" modules="ifconfig" #config_eth0=("dhcp") config_wlan0=("dhcp") modules="wpa_supplicant" wpa_supplicant_wlan0="-Dwext" wpa_timeout_wlan0=60 #ifplugd_eth0="..." dhcpcd_wlan0="-h -E -d -U wlan0" #modules_wlan0=( "!plug" )
All right! From here it was easy. Turns out, it was indeed a configuration problem. Probably caused by an underlying problem long ago that disappeared over time. It was this line in the config: dhcpcd_wlan0="-h -E -d -U wlan0" When I remove this line, the interface comes up and works like a charm. I remember this line being the result of me solving some dhcp related issue long ago. Maybe in connection with this bug, maybe not. I don't remember. All I can see is that the line was already present when I filed this bug. Its there in #Comment 3 and my initial description lets me think its been there a lot longer. Anyway, I can finally mark this one fixed. Another mystery bites the dust and this greatly improves convenience of use for me. Tom, thanks so much for your patience and your help. Much appreciated! Cheers, Stephan
Setting this to verified as I reported and and see that it works now.
