8086:4238 [Lenovo ThinkPad T430s] iwlwifi using 802.11n associates with access point but network is unreachable

[JD Rogers]

While the above bug appears to connect and then slow down eventually failing with packet loss, my problem is almost the opposite. If I can connect, it seems to work fine indefinitely, but initial connections (after suspend, or right after a reboot) only occasionally works. Sometimes, if I wait long enough the connection starts working after several minutes, sometimes it works if I turn off wireless and turn it back on, but often it just never works. According to dmesg, iwlwifi is associating with the access point just fine, but if I ping the ap, I get "netowrk unreachable".

WORKAROUND: 11n_disable=1

After associating, dmesg report:
# dmesg |tail
[101704.467324] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[101704.474053] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[101704.621429] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[101704.717787] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[101704.780532] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[101704.793246] wlan0: authenticated
[101704.797390] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[101704.798226] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x1011 status=0 aid=1)
[101704.802300] wlan0: associated
[101704.802347] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

But network is unreachable.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: linux-image-3.11.0-15-generic 3.11.0-15.25
ProcVersionSignature: Ubuntu 3.11.0-15.25-generic 3.11.10
Uname: Linux 3.11.0-15-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: jdrogers 2276 F.... pulseaudio
Date: Tue Feb 18 12:12:57 2014
HibernationDevice: RESUME=UUID=12dd9e3a-ab8c-468f-a7bc-f3c05e4bcddc
InstallationDate: Installed on 2014-01-01 (47 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MachineType: LENOVO 2352CTO
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.11.0-15-generic root=UUID=b9c20532-4cfc-4833-830a-3d4500621c0e ro rootflags=subvol=@ quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.11.0-15-generic N/A
 linux-backports-modules-3.11.0-15-generic N/A
 linux-firmware 1.116.2
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/24/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: G7ET29WW (1.11 )
dmi.board.asset.tag: Not Available
dmi.board.name: 2352CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrG7ET29WW(1.11):bd05/24/2012:svnLENOVO:pn2352CTO:pvrThinkPadT430s:rvnLENOVO:rn2352CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2352CTO
dmi.product.version: ThinkPad T430s
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This change was made by a bot.

[JD Rogers (rogersjd)]

Hi Christopher,
Thanks for the tips. If bios update turns out to solve this, I will be VERY annoyed since I looked at the change logs for the BIOS just 2 weeks ago, but all that was updated on WIFI was "Added support for a new WiFi device for a specific country".

In any case, I just updated and 802.11n is working at the moment, though this would occasionally work before as well, so I will report back tomorrow after I see if it can reconnect a few times.
Thanks again, JDR

[JD Rogers (rogersjd)]

Behaviour has not changed after BIOS update. Right after I wrote comment #4, I lost the network, but cycling wifi via nm-applet brought it back. Things seemed to otherwise work yesterday, but this morning after resume from suspend it was back to the same: associated with my AP, but pages in browser do not load. I then ping the AP and get "unreachable".

$ sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
G7ET98WW (2.58 )
12/16/2013

# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.10 icmp_seq=1 Destination Host Unreachable
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, +1 errors, 100% packet loss, time 1001ms

# iwconfig
eth0 no wireless extensions.

lo no wireless extensions.

virbr0 no wireless extensions.

wlan0 IEEE 802.11abgn ESSID: <hidden>
          Mode:Managed Frequency:2.437 GHz Access Point: <hidden>
          Bit Rate=78 Mb/s Tx-Power=15 dBm
          Retry long limit:7 RTS thr:off Fragment thr:off
          Encryption key:off
          Power Management:on
          Link Quality=70/70 Signal level=-34 dBm
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:26 Invalid misc:52 Missed beacon:0

# dmesg |tail
[41713.948053] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[41713.954762] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[41714.098900] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[41720.587581] wlan0: authenticate with <hidden>
[41720.599843] wlan0: send auth to <hidden> (try 1/3)
[41720.604907] wlan0: authenticated
[41720.608100] wlan0: associate with <hidden> (try 1/3)
[41720.611883] wlan0: RX AssocResp from <hidden> (capab=0x1411 status=0 aid=5)
[41720.622822] wlan0: associated
[41720.622892] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

[penalvch (penalvch)]

JD Rogers, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, please just make a comment to this.

If reproducible, could you also please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-3.14-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[JD Rogers (rogersjd)]

Christopher, I will try to provide the testing you asked for, but it may be challenging.

I'm not sure if I can reproduce this bug using a live USB stick since the problems most often occur after suspend/resume. This laptop is my primary box for everything, so re-installing the OS is non-trivial. It may be several weeks before I will have the spare time to do testing on the development version.

Testing the kernel OTOH is easy. I installed the mainline a few days ago and so far it is horrible because after resume with the mainline kernel, xorg is a mess: mouse works, but the greeter shows up after 20second pause or my session is already visible from before suspending, but xorg or at least any applications seem unresponsive.

I am sure I have had the symptoms I reported even from a clean boot because once rebooting did not solve the problem and I had to reboot a second time, but it is more rare. The issue is much more common after a suspend/resume cycle. So far the mainline kernel is connecting using 802.11n after suspend resume (at least once), but since I can't reliably suspend/resume, its hard to say. I would not trust that 802.11n working only once or twice after resume means the bug is solved because the failure was never 100% of the time.

I will report back as soon as I can with anything useful.
Thanks,
JDR

[JD Rogers (rogersjd)]

Quick update... I have been using a mainline kernel and it has seemed to be working ok for the past few weeks. I saw the Ubuntu kernel was updated to 3.11.0-18 so I have been trying it again and it seems to be working some of the time as well. Today, after resuming from suspend, the wireless was connected according to nm-applet, but I was unable to ping the local network. Using nm-applet, I turned off wifi and turned it back on, and after connecting, I was still unable to ping. After about 45 seconds, the network started working again. The kernel log shows nothing during this time.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]