Does anyone getting poor WiFi signal on 12th Gen Intel Core using Manjaro? I am using " i7-1260P (Up to 4.7 GHz, 4+8 cores) - AX210 WiFi" chipset.
My WiFi has been noticeably poor comparing with my previous laptops both at work and at home. At home, I am using UniFi NanoHD and none of my other devices had any issues. At work, it is Cisco Merki.
I am wondering if this a known hardware issue or do I need to do some config?
Yes, i noticed it myself but wasnβt sure about it. Also manjaro and 12th gen.
I did not try to see if it gets better when plugged in to power. Was thinking maybe a powersaving feature?
Edit: i donβt have disconnects, but i observe a low signal and only mediocre transfer speeds using 2ghz and 5ghz
I did some further diagnostics:
On my router (UniFi) the Wifi Experience of the laptop is showing good (90 out of 100).
Given the router does not show any issue, could this be a firmware related? Similar thread in ArchLinux: Very slow wifi with AX210 based PCI-E card / Networking, Server, and Protection / Arch Linux Forums
Edit: Iβve tried newer kernels linux61 and linux62 but I got screen flickering issue after logging into i3 . I noticed wifi signal was jumping up and down but not sure this was due to screen flickering or signal improvement.
mhwd-kernel -li
Currently running: 5.15.89-1-MANJARO (linux515)
The following kernels are installed in your system:
* linux515
* linux61
* linux62
Edit2: Fixed the screen flickering issue by switching to XFCE4. Using linux62 kernel. Even next to the router, on 5GHz shows 70% signal.
Connected to (on wlp166s0)
SSID: my-wifi
freq: 5220
RX: 329127 bytes (682 packets)
TX: 99648 bytes (538 packets)
signal: -49 dBm
rx bitrate: 40.5 MBit/s VHT-MCS 2 40MHz VHT-NSS 1
tx bitrate: 400.0 MBit/s VHT-MCS 9 40MHz short GI VHT-NSS 2
bss flags: short-slot-time
dtim period: 3
beacon int: 100
I also have a Unifi AP, the lite version. Signal strength between 45% and 65% (shown in KDE) with a glass door and ~4m away from the router. I also checked what happens if i hold the notebook to the AP (touching it). Then it shows 100% signal strength⦠so maybe thats just correct behaviour? Tested only with 5Ghz band. I did not do an A B Test with my old notebook, but iirc it showed better transfer speeds and higher signal strength (but i wouldnt bet on it, because maybe my memory is tricking me).
Iβve run the same commands as you, maybe it helps.
w wlp166s0 link ο
Connected to (on wlp166s0)
SSID: UniFi
freq: 5220
RX: 105390824 bytes (82485 packets)
TX: 5214645 bytes (23909 packets)
signal: -64 dBm
rx bitrate: 175.5 MBit/s VHT-MCS 4 80MHz VHT-NSS 1
tx bitrate: 390.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 1
bss flags: short-slot-time
dtim period: 3
beacon int: 100
hwd-kernel -li ο
Currently running: 6.1.7-1-MANJARO (linux61)
The following kernels are installed in your system:
* linux515
* linux61
edit: removed bssid
Thanks @barfooss
I tried your kernel 6.1.7 but no difference.
I am using Framework in exactly same location as my previous laptop, signal is at least 10%-20% less. Other devices (e.g. mobile) also getting more signal in the same spot.
Still unsure if this is a software issue or hardware problem.
Not a Framework issue as Iβve seen this with other configurations. Censuses was not an issue on other distros, only was affecting Manjaro users (in a quick search).
pacman -S --needed linux-firmware
Then reboot.
We can also try dropping needed and take a heavier action. This may be going to be an Manjaro forum kind thing though as my Arch days are well behind me. I havenβt had this issue on Ubuntu or Fedora.
Since my focus is on Ubuntu/Fedora, I lack the time to dig into this atm.
@Matt_Hartley -Qs only do a search, it doesnβt do anything. Any other command missing?
> sudo pacman -Qs linux-firmware
local/linux-firmware 20230117.7e4f0ed-1
Firmware files for Linux
local/linux-firmware-whence 20230117.7e4f0ed-1
Firmware files for Linux - contains the WHENCE license file which documents
the vendor license details
That should have been - S pkg name, typo. Should reinstall the package. My Arch commands are rusty as itβs not a focus for me these days.
Itβs fixed above now.
I will say running a rolling distro without something like snapshots (TimeShift for example) is going to be hit and miss with stuff like this.
Hopefully this helps. Iβve seen it work on other manjaro instances.
The reinstallation didnβt help. I also tried different kernels.
* linux515
* linux60
* linux61
* linux62
Circling back to this, letβs tackle this from another angle as you have a connection, be a poor one.
Letβs check your wifi cardβs power status, please run this in the terminal - it will give us your interface name and tell us if your power management is on or off, sort of like the now outdated iwconfig command. But this command only shares those two things:
for interface in $(iw dev | awk '$1=="Interface"{print $2}'); do echo $interface; iw dev $interface get power_save; done
If it comes back as: Power save: on
We can disable powersave with:
for interface in $(iw dev | awk '$1=="Interface"{print $2}'); do sudo iw dev $interface set power_save off; done
> for interface in $(iw dev | awk '$1=="Interface"{print $2}'); do echo $interface; iw dev $interface get power_save; done
wlp166s0
Power save: on
> for interface in $(iw dev | awk '$1=="Interface"{print $2}'); do sudo iw dev $interface set power_save off; done
[sudo] password for user:
> for interface in $(iw dev | awk '$1=="Interface"{print $2}'); do echo $interface; iw dev $interface get power_save; done
wlp166s0
Power save: off
Here is the link status:
> iw wlp166s0 link
Connected to ... (on wlp166s0)
SSID: gost
freq: 5220
RX: 39571 bytes (172 packets)
TX: 27051 bytes (197 packets)
signal: -58 dBm
rx bitrate: 270.0 MBit/s VHT-MCS 7 40MHz VHT-NSS 2
tx bitrate: 108.0 MBit/s VHT-MCS 3 40MHz VHT-NSS 2
bss flags: short-slot-time
dtim period: 3
beacon int: 100
Also Rebooted and disabled power save again.
The signal strength remained the same ~ %65. Another device in the same location is getting ~%100. AP is a meter away, ceiling hanging, separated by a wooden wall.
So it looks like power save was on, now itβs off. Did you reboot after or restart network manager?
Also is this data 65% coming from wavemon?
Can to install and run wavemon from the terminal, then take a screenshot please? This will provide me with a useful visual of your link quality and signal level.
While it shouldnβt be a big deal, wifi saturation/noise, even a wood wall can drag things down a little bit even when it works great with say, a smart phone. But letβs start by looking at your wavemon output.
wavemon output with power save on (hmm⦠link quality is showing 93%!)
ββInterfaceββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
βwlp166s0 - wdev 1, phy 0, reg: n/a, SSID: gost β
ββLevelsβββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
βlink quality: 93% (65/70) β
β===================================================================== β
β β
β β
βsignal level: -45 dBm (0.03 uW) β
β============================================= β
β β
ββPacket Countsββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
βRX: 29k (26.21 MiB), drop: 1,583 (5.5%) β
βTX: 11k (14.59 MiB), retries: 597 (5.4%) β
ββInfoβββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
βmode: Managed, connected to: ..., time: 33:19m, inactive: 8.0s
βfreq: 5220 MHz, ctr1: 5230 MHz, channel: 44 (width: 40 MHz), bands: 2 β
βbeacons: 9,719, avg sig: -44 dBm, interval: 0.1s, DTIM: 3 β
βrx rate: 6.0 MBit/s β
βtx rate: 400.0 MBit/s VHT-MCS 9 40MHz short GI VHT-NSS 2 β
βtx power: 22 dBm (158.49 mW), power save: on β
βretry short/long: 7/4, rts/cts: off, frag: off β
ββNetworkββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
βwlp166s0 #2 (UP RUNNING BROADCAST MULTICAST) β
βmode: dormant, qdisc: noqueue, qlen: 1000 β
βmac: ... β
βip4: 192.168.1.160/24, valid: 1:26h β
βip6: n/a β
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
wavemon output after turning off power save. Disabling and enabling network in network manager and reconnecting to the AP
ββInterfaceββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
ββInterfaceββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
βwlp166s0 - wdev 1, phy 0, reg: n/a, SSID: gost β
ββLevelsβββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
β β
βlink quality: 93% (65/70) β
β===================================================================== β
β β
β β
βsignal level: -45 dBm (0.03 uW) β
β============================================= β
β β
ββPacket Countsββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
βRX: 29k (26.21 MiB), drop: 1,583 (5.5%) β
βTX: 11k (14.59 MiB), retries: 597 (5.4%) β
ββInfoβββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
βmode: Managed, connected to: ..., time: 33:19m, inactive: 8.0s
βfreq: 5220 MHz, ctr1: 5230 MHz, channel: 44 (width: 40 MHz), bands: 2 β
βbeacons: 9,719, avg sig: -44 dBm, interval: 0.1s, DTIM: 3 β
βrx rate: 6.0 MBit/s β
βtx rate: 400.0 MBit/s VHT-MCS 9 40MHz short GI VHT-NSS 2 β
βtx power: 22 dBm (158.49 mW), power save: on β
βretry short/long: 7/4, rts/cts: off, frag: off β
ββNetworkββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ€
βwlp166s0 #2 (UP RUNNING BROADCAST MULTICAST) β
βmode: dormant, qdisc: noqueue, qlen: 1000 β
βmac: ... β
βip4: 192.168.1.160/24, valid: 1:26h β
βip6: n/a β
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
This was only to take effect while booted up. I donβt have an Arch/Manjaro install in front of me, however this should get you in the right direction for persistent power save off.
https://wiki.archlinux.org/title/Power_management#Intel_wireless_cards_(iwlwifi)
Setting options iwlwifi power_save=1 did not disable power saving permanently for me. Investigating β¦
@Hoshang Thatβs because you should try with =0.
Reading the Arch wiki page, they say
Additional power saving functions of Intel wireless cards with
iwlwifidriver can be enabled by passing [β¦]options iwlwifi power_save=1
which means that the =1 option is to enable power saving, thus it would make sense to use =0 in order to disable power saving.
This is correct. 1 is on and 0 is off.
Yes, I tried with = 0 (see below). When I copied the command from Arch wiki page to this threat I made a typo and didnβt change it to 0.
cat /etc/modprobe.d/iwlwifi.conf
options iwlwifi power_save=0
iw dev wlp166s0 get power_save
Power save: on
Either config file location may be different or there maybe other settings?
It looks as power_save by default is disabled:
modinfo iwlwifi | grep parm ξ² 0|1 β
parm: debug:debug output mask (uint)
parm: swcrypto:using crypto in software (default 0 [hardware]) (int)
parm: 11n_disable:disable 11n functionality, bitmap: 1: full, 2: disable agg TX, 4: disable agg RX, 8 enable agg TX (uint)
parm: amsdu_size:amsdu size 0: 12K for multi Rx queue devices, 2K for AX210 devices, 4K for other devices 1:4K 2:8K 3:12K (16K buffers) 4: 2K (default 0) (int)
parm: fw_restart:restart firmware in case of error (default true) (bool)
parm: nvm_file:NVM file name (charp)
parm: uapsd_disable:disable U-APSD functionality bitmap 1: BSS 2: P2P Client (default: 3) (uint)
parm: enable_ini:0:disable, 1-15:FW_DBG_PRESET Values, 16:enabled without preset value defined,Debug INI TLV FW debug infrastructure (default: 16)
parm: bt_coex_active:enable wifi/bt co-exist (default: enable) (bool)
parm: led_mode:0=system default, 1=On(RF On)/Off(RF Off), 2=blinking, 3=Off (default: 0) (int)
parm: power_save:enable WiFi power management (default: disable) (bool)
parm: power_level:default power save level (range from 1 - 5, default: 1) (int)
parm: disable_11ac:Disable VHT capabilities (default: false) (bool)
parm: remove_when_gone:Remove dev from PCIe bus if it is deemed inaccessible (default: false) (bool)
parm: disable_11ax:Disable HE capabilities (default: false) (bool)
parm: disable_11be:Disable EHT capabilities (default: false) (bool)
So not sure why I see it on here (this is after reboot):
iw dev wlp166s0 get power_save
Power save: on
cat /etc/modprobe.d/iwlwifi.conf
options iwlwifi power_save=0
Ok, so maybe a possible fix for now would be to put it into your .bashrc?
Or, if you are ready to take this challenge, you could also create a SystemD service to do it on boot (but unfortunately I am not too familiar with SystemD).