Intel Wireless 7260 [8086:08b2] Subsystem [8086:4262] Wifi requires interruption before timing out (and immediate reconnect attempt succeeds)

Bug #1867534 reported by MarkF
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

ISO testing 20.04 Lubuntu daily (20200315). From the Live desktop, I click my nm-tray access point, supply the password. nm-tray will timeout. Trying again will timeout. What works is clicking the same access point a couple times before it times out. This causes an immediate failure and successful connection (two balloon msgs).

This problem is not specific to Lubuntu. It happens with Kubuntu, Budgie, Mate, Xubuntu. The common theme is: it appears to be out of sync in some manner. The wifi connection needs to be interrupted before timing out. Then an immediate attempt (within 2-3 seconds? I haven't tested how long it can wait) succeeds.

This problem also happens after install and reboot. For example, with yesterday's daily image (20200314), I had to reboot Lubuntu twice after install before the wifi worked. (I haven't reached that point yet today. I'm creating this bug report from the Live desktop. I will update with more info about post-install.).

Note: I don't know if this is acceptable wifi behavior. Good enough? I figured I should report it and let someone decide. It seems to be specific to this laptop (Lenovo Thinkpad E440 20C5) or it's Intel 7260 wifi card.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-14-generic 5.4.0-14.17
ProcVersionSignature: Ubuntu 5.4.0-14.17-generic 5.4.18
Uname: Linux 5.4.0-14-generic x86_64
ApportVersion: 2.20.11-0ubuntu20
Architecture: amd64
 /dev/snd/controlC1: lubuntu 1857 F.... pulseaudio
 /dev/snd/controlC0: lubuntu 1857 F.... pulseaudio
CasperVersion: 1.441
Date: Sun Mar 15 17:17:43 2020
LiveMediaBuild: Lubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200315)
MachineType: LENOVO 20C5004YUS
ProcFB: 0 i915drmfb
ProcKernelCmdLine: file=/cdrom/preseed/username.seed initrd=/casper/initrd quiet splash ---
 linux-restricted-modules-5.4.0-14-generic N/A
 linux-backports-modules-5.4.0-14-generic N/A
 linux-firmware 1.186
SourcePackage: linux-5.4
UpgradeStatus: No upgrade log present (probably fresh install) 06/20/2018
dmi.bios.vendor: LENOVO
dmi.bios.version: J9ETA2WW (2.28 )
dmi.board.asset.tag: Not Available 20C5004YUS
dmi.board.vendor: LENOVO
dmi.board.version: 0B98401 PRO
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvrJ9ETA2WW(2.28):bd06/20/2018:svnLENOVO:pn20C5004YUS:pvrThinkPadEdgeE440:rvnLENOVO:rn20C5004YUS:rvr0B98401PRO:cvnLENOVO:ct10:cvrNotAvailable: ThinkPad Edge E440 20C5004YUS
dmi.product.sku: LENOVO_MT_20C5_BU_Think_FM_ThinkPad Edge E440
dmi.product.version: ThinkPad Edge E440
dmi.sys.vendor: LENOVO

Revision history for this message
MarkF (az2008) wrote :
Revision history for this message
MarkF (az2008) wrote :

This bug was reported from the Live desktop. After installing & rebooting Lubuntu, it behaves the much the same way. Letting the wifi connection-attempt timeout results in a "connection lost" and "connection established" balloon msg (together on the screen).

Subsequent reboots don't seem to improve the behavior. Sometimes interrupting the pending timeout will cause that same behavior to happen sooner. Sometimes I have to click the access point again to make the "connection established" happen. Sometimes it happens automatically. But, it always has to fail before it connects. I haven't seen it connect successfully. It seems like it's out of sync with whatever's happening.

Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Revision history for this message
MarkF (az2008) wrote :

UPDATE: This wifi behavior happens with all the Ubuntu desktop distros. HOWEVER: I just installed 20.04 Ubuntu Server daily-image (20200320). It did NOT have this behavior.

As I began the text-based install, I wondered how I would interrupt the connection in order to make it work. But, it just worked. I haven't seen any desktop do that. They all timeout. They all require some clicking on the access point to interrupt that timeout, causing it to connect.

So, the problem seems to be specific to desktop distros. (If it were a driver problem, I think it would have happened with the server distro too.).

affects: linux-5.4 (Ubuntu) → linux (Ubuntu)
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
You-Sheng Yang (vicamo)
tags: added: hwe-networking-wifi
summary: - Wifi requires interruption before timing out (and immediate reconnect
- attempt succeeds)
+ Intel Wireless 7260 [8086:08b2] Subsystem [8086:4262] Wifi requires
+ interruption before timing out (and immediate reconnect attempt
+ succeeds)
Norbert (nrbrtx)
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers