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.
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)
WPA3 is not honored throughout text
There is a section on specialties of WPA3, fine. But since WPA3 will be default in the near future, it should be treated as such, resulting in a general overhaul of the text. E.g. the table which package supports which encryption has a column for WEP and one for WPA/WPA2 but WPA3 is not mentioned at all. If netctl is default, there should be a complete configuration example aswell. Nursoda (talk) 16:30, 27 September 2020 (UTC)
iwlwifi no longer supports swcrypto and bt_coex_active as of version 5.8 of the kernel
It seems that both the
bt_coex_active module options for iwlwifi (or at least for iwlmvm) have been removed in Linux 5.8. I see this is my syslog during startup as I have
iwlwifi 0000:01:00.0: iwlmvm doesn't allow to disable BT Coex, check bt_coex_active module parameter
This patch might be worth looking at. From the listed changes:
iwlwifi: mvm: stop supporting swcrypto and bt_coex_active module parameters
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)