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)
- I believe it is the security password configured on the router. Silverhammermba (talk) 12:47, 11 March 2016 (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)