iwlist uses outdated interfaces, and iw works better with modern wireless drivers. Can we remove the wireless_tools options from Wireless_network_configuration#Manual_setup? Pid1 (talk) 15:11, 3 October 2015 (UTC)
- Many sections in Wireless_network_configuration#Troubleshooting still suggest only iwconfig commands. We need to find equivalent iw options first... -- Lahwaacz (talk) 15:21, 3 October 2015 (UTC)
Setting regulatory domain
In the section Respecting the regulatory domain in my opinion the following information should be added:
Another reason for an unchanged regulatory domain after adjusting the settings can be the fact, that linux uses information about the regulatory domain provided by the access point. As far as I unterstand these information are only retrieved, if the PC is associated with the access point. For details see:  (subsection: Country IE processing)
It says "WPA supplicant can also use a regdomain in the country= line of /etc/wpa_supplicant/wpa_supplicant.conf." I cannot find such a setting in the man page for either wpa_supplicant or wpa_supplicant.conf.
The page says you can use either crda or wireless-regdb. However, I only found success with crda.
I have updated the section on the Realtek USB chipsets for AC1200/1750/1900, respectively 8812au/8821au/8814au.
I maintain two of them on the AUR and situation is complicated. But I was asked to give some insights on the state of these drivers.
Realtek drivers are a mess. Three things to consider:
- the driver version (4, 5.1.5, 5.2.9). It is a fair bet that the higher the better, considering the feedbacks we see on Github. However, not all chipsets are at the same level due to hal code missing (see point 3).
- the kernel patching level. A lot of these drivers do not work anymore because the upstream maintainer (on Github mostly) do not patch their code for the latest kernels. Thankfully the solutions are available, and it is easy to patch, but we probably need to nuke all those outdated Github repositories.
- the hal code. Realtek do not provide unified drivers. Hence the chipsets not having the same capabilities. So 8812, 8821 and 8814 have not been dispatched with the whole hal code for every chipset and versions are not in sync. Some people on github have done some work to add the various hal branches, but there is no one-for-all solution since it is not guaranteed that they all work with the same driver revision. Adding to that, I only have a 8812 dongle, so am unable to test for other chipsets before patching.
As of today, and to the best of my knowledge, there are a few Github repos that have the latest possible driver AND the latest kernel patches (hence do work with a rolling release distro like ArchLinux):
- 8812au: my repo (zebulon2), forked from gordboy's repo. Firmware 5.2.9, hal code for 8812 only. I just tried to change txpower but realtek have modified the config options, so there is a bit of a power issue there. Otherwise it works fine.
- 8821au: my repo, forked from paspro's repo. Firmware 5.1.5, hal code for both 8821 and 8812. We are stuck at 5.1.5 because of the lack of hal code for 8821 and 5.2.9. Note this also works for unint where it is more difficult. bsdfirst repo has firmware 4.3.21 and this is working for kernels 4.12/4.11 (AUR https://aur.archlinux.org/packages/edimax_ac1750_8814au-dkms/). There is however a 5.1.5 repo tree from astsam. It seems he has been abale to merge the 5.1.5 and hal code for 8814 from previous series. I have suggested to the maintainer he tries this. However, he would need to add the kernel patches 4.11/4.12 because astsam has not done this yet. But if it were working 8814 users would have the driver 5 series too (which is much better). I would be happy to open a repo on Github and do this. However I have no 8814 device for testing myself, so we would have to release and ask people to give feedback.
Sorry for being very complicated, but it is indeed complicated.
Finally I'll need some guidance on how to handle the renaming scheme (I suppose we need to use 'replace' in the PKGBUILD)? Is there a guidance for naming kernel drivers?
Having experienced issues with the default install of unified kernel module rtl8xxxu, I am able to confirm the apparent flawless functioning of the third party rtl8723bu module, as provided by lwfinger in his repo collection. This has been the case for the last few kernel releases, and remains so, for 4.14.14-1. It should be noted that by default, the driver operates the hardware as a station and access point simultaneously. Thus will show two wireless devices when you run the 'iwconfig' or 'ip link show' commands.
Should anyone else be having issues with this particular chipset, the above is well worth trying. I'd also be interested to receive feedback.
WPA2 enterprise and NetworkManager CLI
According to Wireless_network_configuration#NetworkManager, NetworkManager cannot create a WPA2 Enterprise profile with any frontend other than the graphical ones. But when googling this for someone in #archlinux-newbie, I hit this link before I saw the wiki here.
- Neither can I, but best way to get attention is to add Template:Accuracy with the stack overflow link. Silverhammermba (talk) 18:10, 13 November 2017 (UTC)
Wireless management rewrite
The original Wireless management section ceased to exist, instead, the page describes only the "manual setup". The only reference to the "automatic setup" (currently Network configuration#Network managers) is in the introduction, something along the way "if you want to use a network manager, go there and don't come back". There should still be an explicit section to avoid this, and also to mention combinations like (wpa_supplicant or iwd) + (dhcpcd or systemd-networkd), which you won't find on these two pages. Maybe overly long, but the intro from 2017 had a purpose which should be restored. -- Lahwaacz (talk) 20:14, 22 May 2018 (UTC)
iwlwifi argument suggestion no longer does what it seems on recent kernels
I only just came across this when my laptop was only connecting to access points with a 20MHz bandwidth, in the end the Gentoo wiki had noted that on recent kernels setting the option to 1 disables 802.11ac on recent kernels. I would add a warning, but i am not sure about the etiquette regarding adding the same warning here. Ioangogo (talk) 10:41, 2 August 2020 (UTC)
Add info about fixing iwlwifi by disabling power saving in iwlmvm
I have an HP 14z-fq000, and for the life of me, I couldn't figure out how to fix an issue with its WiFi card disabling whenever the device was unplugged. Turns out the issue was with iwlmvm, and I had to set its power scheme to disable power saving.
This fix was pretty difficult to find (I just happened to come across it on a Debian forum) so I was wondering if maybe we should add it here?
It's outlined in this forum post: https://bbs.archlinux.org/viewtopic.php?pid=1940495#p1940495 (and was also suggested that I bring up the idea to add the info here).
The fix was to add
options iwlmvm power_scheme=1 to
The article already includes information about power saving modes, albeit in another page. In my opinion, however it isn't immediately obvious that this is the fix, so maybe it should be added? PJBeans (talk) 05:00, 30 November 2020 (UTC)
- Feel free to add a note with the fix and a reference to the forum post. -- Lahwaacz (talk) 10:21, 30 November 2020 (UTC)
Observing logs: Check the journal, not the dmesg
In Network configuration/Wireless#Observing logs it is mentioned to check the dmesg and the journal. It is unnecessary to check both because the journal includes the dmesg by default.
journalctl -f will show both the kernel logs and all other things in the journal. I would like to remove the mention of dmesg and replace it with journalctl.
--grep (see ) can also be used to grep the journal, so the user does not need to pipe it into grep (applies to other sections such as Network configuration/Wireless#Check the driver status)
- I agree. While not relevant for this use case, the kernel ring buffer has a limited size so when it's full, old messages get evicted as new ones come in. Journal doesn't have this issue. -- nl6720 (talk) 11:16, 2 February 2021 (UTC)
rtw88 and rtw89
Should info be added about the rtw88 (for RTL8822BE, RTL8822CE, RTL8821CE, and RTL8723DE)  and rtw89 (for 8852AE)  drivers? (Should be present on current kernels) Archcat (talk) 16:47, 12 August 2021 (UTC) —This unsigned comment is by Archcat (talk) 15:19, 12 August 2021 (UTC). Please sign your posts with ~~~~!
- There is a RTW88 section now. Please check if you have any info to add. --Fengchao (talk) 06:13, 31 December 2022 (UTC)
Network configuration/Wireless#Rfkill caveat now lives in Tips and tricks section. It is not a tip nor a trick. It is one important steps needed for some machines.
RTNETLINK answers: Operation not possible due to RF-kill is not the only problem when device is hard/soft blocked. I got the habit that whenever the wireless device is not working, check rfkill first. So it should be moved up as first utility in Network configuration/Wireless#Utilities to make sure the device is not blocked. Thoughts? --Fengchao (talk) 13:39, 26 December 2022 (UTC)
- It is not a "utility" either. There is already a note in Network configuration/Wireless#Check the driver status which is high enough in the article. — Lahwaacz (talk) 16:39, 26 December 2022 (UTC)
- The error message in Network configuration/Wireless#Check the driver status only said one error message. I also encounter other problems that are caused by soft block. For example iwctl just return nothing during device scan. With current wiki text, users could not link such issue with rfkill directly.
- We could just notice users to explicitly check rfkill status that it is not blocked. We can not/should not list every fail situations. --Fengchao (talk) 13:39, 27 December 2022 (UTC)
- I don't like instructions like "try this if something does not work". The references to rfkill should appear where relevant and not as a catch-all fallback solution. If iwctl does not show any error or info when the device is blocked, that is its problem that should be solved on the iwd page. — Lahwaacz (talk) 18:29, 27 December 2022 (UTC)
- Exactly, I make the wording more clear that users should check device is unblocked. It is much better now. Jump forward/backward is still needed that's what I dislike. But the section is a little too long to fit there. So I leave it to someone else for further improvement. --Fengchao (talk) 13:05, 28 December 2022 (UTC)
- I don't think your change made things more clear. Reverted, because the
RTNETLINK answers: Operation not possible due to RF-killerror message is relevant for the
ip linkcommand in Network configuration/Wireless#Check the driver status, moving it to Network configuration/Wireless#Rfkill caveat does not make sense. — Lahwaacz (talk) 13:16, 28 December 2022 (UTC)
- I don't think your change made things more clear. Reverted, because the