0

I have recently installed 18.04 on a friends' brand new laptop. Everything worked flawlessly. The laptop could connect to all access points we tried. Except for one... There is one particular access point (the access point the ISP's modem provides) that it does not want to connect to. The wifi status stays on "connecting" for almost a minute, and then asks for the password again. This password has been checked multiple times, but is definitely correct. All other devices in the house (including a different laptop with Ubuntu 18.04) can connect just fine with this network that hasn't been altered in years.

I pasted the output of dmesg here (Truncated version, it showed this output multiple times). Not sure what the relevant parts of the dump are, but these lines looked interesting to me:

[12059.864549] iwlwifi 0000:00:14.3: Failed to send binding (action:3): -5
[12059.864552] iwlwifi 0000:00:14.3: Failed to send MAC context (action:2): -5
[12059.864553] iwlwifi 0000:00:14.3: failed to update MAC c8:09:a8:ee:b1:55
[12059.864556] iwlwifi 0000:00:14.3: PHY ctxt cmd error. ret=-5
[12059.885003] iwlwifi 0000:00:14.3: Applying debug destination EXTERNAL_DRAM
[12060.034524] iwlwifi 0000:00:14.3: FW already configured (0) - re-configuring
[12069.158052] wlp0s20f3: authenticate with dc:53:7c:34:56:17
[12069.162964] wlp0s20f3: send auth to dc:53:7c:34:56:17 (try 1/3)
[12069.222006] wlp0s20f3: authenticated
[12069.224063] wlp0s20f3: associate with dc:53:7c:34:56:17 (try 1/3)
[12069.238359] wlp0s20f3: RX AssocResp from dc:53:7c:34:56:17 (capab=0x411 status=0 aid=1)

It seems like authentication works just fine, but association fails. Also, there seem to be some hardware/driver issues. Googling this output didn't bring up much relevant results.

I then found Unable to connect to specific wifi network . This question looks identical, but unfortunately the solution didn't work.

Because I suspected a driver problem, I checked the "Additional Drivers" tab in Software & Updates. It showed me Intel Corporation: Unknown device. The options to choose from were greyed out.

After a lot more unsuccessful experimenting, I erased the drive and installed Ubuntu 20.04, in the hopes that this would fix it (Because I read something on a page where they suggested a fix that did not work for me on 18.04, but was supposed to be already included in 20.04). Unfortunately, the problem persisted. This time however, in "Additional Drivers" it showed the model of the wifi-card: AC-9462. Googling this model showed a bunch of Linux users having problems with this card. Including this one: Intel Wireless AC 9462 not working w/ 18.04 LTS . I was very hopeful at this point. I installed the fix (the one from the PPA). It "un-greyed" the options in Additional Drivers, but unfortunately did not fix the connection issue.

Then finally I stumbled on this page: https://bugzilla.kernel.org/show_bug.cgi?id=201319 . Multiple users reported Windows Fast Boot to be the culprit, and disabling it solved the issue for them. It is speculated that Windows alters the device in some way, preventing Linux from using it.

This is also written on the wiki of kernel.org: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_dual-boot_with_windows_and_fast-boot_enabled

I quote:

About dual-boot with Windows and "fast-boot" enabled

If you have a dual-boot machine with a recent version of Windows and start seeing problems during initialization of the WiFi device when booting Linux, the problem could be due to the “fast startup” feature on Windows.

With this feature enabled, Windows don't really shut down the entire system, but leaves things partially running so you can start the machine faster again. Try to disable this option, on Windows 10 it should be in “Control Panel→Hardware and Sound→Power Options→System Settings”, then disable the “Fast Startup” option in “Shutdown Settings”. This will cause Windows to fully shutdown and may solve the issue.

Even though everyone unanimously agreed that this was the issue, I'm a bit skeptical if this is the issue in my case. Windows was installed on this computer, yes. But it was removed entirely before installing Linux. I don't think remnants of it can cause this issue, can it? In case the answer is "Yes they can!", then how can I fix this? Because Windows has been removed entirely, I can't open the control panel to disable the fast boot option anymore... (I did disable Fast Boot in the BIOS, but this is an entirely different setting if I understand it correctly)

So, after hours of trying and experimenting, I've run out of ideas... Anyone know how I can fix this?

As requested by @chilli555 :

Linux firmware: Version: 1.187

/lib/firmware:

iwlwifi-9000-pu-b0-jf-b0-33.ucode
iwlwifi-9000-pu-b0-jf-b0-34.ucode
iwlwifi-9000-pu-b0-jf-b0-38.ucode
iwlwifi-9000-pu-b0-jf-b0-41.ucode
iwlwifi-9000-pu-b0-jf-b0-43.ucode
iwlwifi-9000-pu-b0-jf-b0-46.ucode

Output of dmesg when connecting to a different access point, and output of iwlist chan Output of iwlist scan

8
  • If your wireless works with any access points at all, then Fast Boot is not an issue.
    – chili555
    Apr 27, 2020 at 19:52
  • Please edit your question to show the result of: sudo dpkg -s linux-firmware | grep Version and also: ls /lib/firmware | grep iwlwifi-9000-pu-b0-jf-b0 Your system seems to load -48 and has problems.
    – chili555
    Apr 27, 2020 at 20:01
  • We see many alrming messages in your log; not just a failure to associate with one access point: paste.ubuntu.com/p/YbWF7hKHC9 When you connect normally to other access points, do all these errors, warnings, etc. appear again or no? What is peculiar about this access point? Is it on a channel that your device also has? sudo iwlist chan It it a new 802.11AX device? Or what?? Reference for chili: iwlwifi-QuZ-a0-jf-b0-48.ucode and not quite related: askubuntu.com/questions/1229226/…
    – chili555
    Apr 28, 2020 at 15:27
  • @chili555 I don't think the same errors show up when connecting to any other access points: pastebin.com/zWWF5BTP The access point to which we connect in this pastebin is from a Devolo wifi-extender. But we've also been successful in connecting to a regular router. The access point that fails to connect is a Eurodocsis 3.x modem with a built-in access point provided by the ISP. It hasn't been changed in several years, so I doubt that it is 802.11AX. The output of iwlist chan is in the same pastebin.
    – Opifex
    Apr 28, 2020 at 19:49
  • What channel is the Eurodocsis 3.x modem broadcasting on? Auto channel select or a fixed channel that is the list in the pastebin? Does the modem appear in: sudo iwlist scan? Pastebin, please.
    – chili555
    Apr 28, 2020 at 20:00

1 Answer 1

0

First, check the settings in the router. WPA2-AES is preferred; not any WPA and WPA2 mixed mode and certainly not TKIP. Second, if your router is capable of N speeds, you may have better connectivity with a channel width of 20 MHz in the 2.4 GHz band instead of automatic 20/40 MHz, although it is likely to affect N speeds. I also have better luck with a fixed channel, either 1, 6 or 11, rather than automatic channel selection. Also, be certain the router is not set to use N speeds only; auto B, G and N is preferred. After making these changes, reboot the router.

Then set your regulatory domain explicitly. Check yours:

sudo iw reg get

If you get 00, that is a one-size-maybe-fits-all setting. Find yours here: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 Then set it temporarily:

sudo iw reg set IS

Of course, substitute your country code if not Iceland. Set it permanently:

sudo nano /etc/default/crda

Change the last line to read:

REGDOMAIN=IS

Proofread carefully, save (Ctrl+O followed by Enter) and close (Ctrl+x) the text editor.

EDIT: The driver iwlwifi includes a few manipulable parameters that may be helpful. Let's try a few:

First, remove the loaded module:

sudo modprobe -r iwlwifi

Next, reload the driver module with a parameter:

sudo modprobe iwlwifi disable_11ac=Y

Is there any improvement? If not, unload the module and try another parameter:

sudo modprobe -r iwlwifi
sudo modprobe iwlwifi 11n_disable=8

Again, is there any improvement?

You might try another parameter:

sudo modprobe -r iwlwifi
sudo modprobe iwlwifi swcrypto=1   

If you find a parameter that seems to fix the issue, make it persistent:

sudo -i
echo "options iwlwifi some_parameter"  >>  /etc/modprobe.d/iwlwifi.conf
exit

Of course, substitute the parameter you found useful here.

7
  • We tried this, it did not work unfortunately. I'm also a bit confused on why this should work? How would a wrong regulatory domain (or an unset one), cause these driver-errors?
    – Opifex
    Apr 30, 2020 at 15:45
  • It is simply included in a list of several steps that have often proved helpful in improving connectivity in Intel wireless devices including mine. The crda step is because some channels are available in some domains but not others. I had hoped that the fixed channel might be most useful to you.
    – chili555
    Apr 30, 2020 at 16:27
  • Unfortunately not. Got any other ideas on your list? What do you think is the most likely cause of the issue? The modem/router? The wifi-card? The Linux-drivers? Because the notebook is still in warranty. If you think the wifi-card is the most likely culprit, then we'll probably send it back.
    – Opifex
    Apr 30, 2020 at 16:36
  • We appreciate all the effort you're putting into this btw!
    – Opifex
    Apr 30, 2020 at 16:36
  • Please see my edit above in a few minutes. I think that Intel devices are usually very reliable. I will use none other. I suspect that the hardware, driver and firmware are having a problem with your wifi extender; for what reason, I can't even guess. I have never seen this exact issue before and apparently neither has Google.
    – chili555
    Apr 30, 2020 at 21:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .