Talk:Wireless network configuration
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)
NetworkManager and dhcpcd
Hello all, The following edit I made was deleted:
Dropped connection with dhcpcd and eduroam
The wireless connection sometimes stops working even though it appears to be connected in NetworkManager. This has been particularly problematic with the Eduroam network. A suggested fix is to replace dhcpcd with dhclient.
# systemctl disable dhcpcd.service # pacman -S dhclient
then add the following to /etc/NetworkManager/NetworkManager.conf:
(User:Lahwaacz (Undo revision 513120 by Trougnouf (talk) - not an Eduroam problem, mixing dhcpcd.service and NetworkManager is never going to work (and there are warning against it everywhere)) (undo)
I don't see the warnings against running dhcpd and NetworkManager everywhere. It is the configuration I've always had when installing manually, and it's what Anarchy Linux installs by default. Moreover a lot of users suffer with the same problem according to the forum post, and I didn't see the solution until today (over a year after I initially experienced the problem).
The wiki does mention that mixing the two can result in not being able to obtain an IP, however that was not the issue experienced and I wouldn't have seen it if I wasn't specifically looking for mentions of dhcpcd/NetworkManager.
- See e.g. NetworkManager#Installation, Network_configuration#Network_managers and Wireless_network_configuration#Automatic_setup. In Arch, the
dhcpcd.serviceis not enabled automatically after installation. If other distributions behave differently, they should document it on their own. -- Lahwaacz (talk) 15:29, 9 March 2018 (UTC)
- In any case, it is a NetworkManager problem and the solution is already described in NetworkManager#Problems_with_internal_DHCP_client (it even mentions "eduroam"). So I think this can be closed. -- Lahwaacz (talk) 15:43, 9 March 2018 (UTC)
- I mentioned it on their bugtracker. I still think the issue/solution is worth mentioning in Wireless network configuration, it is not obvious to a normal user what the difference between dhclient and dhcpcd is (or that they are network daemons that overlap with NetworkManager's function), and while two of the links you posted mention that the daemons are mutually exclusive, Wireless_network_configuration#Automatic_setup does not even include dhcpcd as one such daemon like in Network_configuration#Network_managers, probably because it's not an automatic setup, but in the end we have no indication that they are incompatible on this page except for being unable to obtain an IP address in some cases which is not the issue here. Perhaps we could expand Wireless_network_configuration#Failed_to_get_IP_address to include it since it is the same cause / solution. --Trougnouf (talk) 16:03, 9 March 2018 (UTC)
- The user should know which connection manager he is using. If he ever enabled
dhcpcd.service, he should know what it is and disable it when he moves to NetworkManager (or anything else). In this case the documentation is pretty much complete, there is nothing to add. And since the "fix" involving NetworkManager configuration is naturally described on the NetworkManager page, I don't see what more do you want from this page?
- Of course, since you're not using Arch Linux, you should look into different documentation altogether.
- -- Lahwaacz (talk) 16:39, 9 March 2018 (UTC)
- The user should know which connection manager he is using. If he ever enabled
- I added a couple bits on NetworkManager#Problems with internal DHCP client since the issue described wasn't the same (not getting an IP is not the same as losing internet after some time with no disconection, and it's clearly an issue that users experience as you can see in the BBS link I posted that gathered 32 messages), and a note in Wireless network configuration#Automatic setup mentioning incompatibily issues with dhcpcd which wasn't mentioned there.
- I am using Arch Linux and I really don't appreciate you telling me that I should find another community because using an automated installer isn't up to your standards. I am very proud to be part of this community and have an immense appreciation for all the excellent work that is done in development and documentation. Your comment is not what I expect from an Arch community administrator. --Trougnouf (talk) 20:21, 9 March 2018 (UTC)
- Anarchy Linux is not Arch Linux so either this or this of your posts is providing incorrect information.
- Anyway, there are exactly two unrelated issues being solved in this post and the fact that your solution comes from the Arch forums does not mean that it is suitable for the Arch wiki. First, you need to disable the conflicting service and then you should check if the issue persists. If there is no conflicting service and the second step is still necessary, saying to disable dhcpcd is absolutely useless. -- Lahwaacz (talk) 20:44, 9 March 2018 (UTC)
- "A Linux distribution (often abbreviated as distro) is an operating system made from a software collection, which is based upon the Linux kernel and, often, a package management system."
- My /etc/pacman.conf file is the one provided by . Maybe you are confusing Anarchy Linux (an Arch Linux installer) with Manjaro Linux which has its own repositories, I am as much an Arch Linux user now as you (presumably), myself when I did manual instals, and anyone else running these packages.
- I will test leaving Trougnouf (talk) 21:12, 9 March 2018 (UTC) enabled next time I am on campus. --
- The very first sentence on the Anarchy Linux homepage says that "Anarchy Linux is a distribution [...]". Since you have not installed Arch Linux, the Arch community cannot support you regardless if you use the same source of packages because we have no idea how the unsupported installer modified the system configuration. If this is not sufficiently clear from their website or other resources, please file a bug report on their bug tracker. Also, consider reinstalling your system the Arch way ;-) -- Lahwaacz (talk) 21:37, 9 March 2018 (UTC)
- The anarchy linux homepage can claim whatever it wants, their work doesn't amount to a distribution as it is commonly defined and that is largely agreed on by the community. I've already gotten support from the community by reading the forum page and I am working on making this documentation more accessible and reliable. Please don't mark this post for removal yet as I need to do further testing (within a week) so that I can restore some of the content you removed from NetworkManager#Problems with internal DHCP client (which is, as you mentioned, where the issue belongs). --Trougnouf (talk) 21:51, 9 March 2018 (UTC)
- The community "by and large" agrees that only Arch is supported. See Code_of_conduct#Arch_Linux_distribution_support_.2Aonly.2A. Please don't waste our time with issues that you can't replicate on Arch. Closing. -- Alad (talk) 23:21, 9 March 2018 (UTC)
- I am using Arch, and regardless, this issue is not related to a configuration specifically introduced by Anarchy Linux but simply by "systemctl enable dhcpcd" which is something I previously did myself on a "pure Arch" installation (at the time I didn't know about this fix and I was able to get my setup to work consistently by using the non-free broadcom driver), and as you witnessed in the forum, many Arch users have as well (it generated 32-posts until someone came up with the fix I am trying to document and am willing to further investigate).
- Refusing my provably valid contributions here on the basis that I used an unsupported installer is akin to removing my AUR contributions, it makes no sense whatsoever and is alienating. I am not asking for support but trying to provide support that the whole Arch community can use.--Trougnouf (talk) 23:46, 9 March 2018 (UTC)
- I did not use the "non-Arch argument" even a single time when undoing your changes. You are making false claims about your system and other people's edits, and completely disregard the fact that a solution is already mentioned in the right place. You have already concluded that you need to make more testing so please go do that and stop wasting time on this silly discussion. -- Lahwaacz (talk) 00:29, 10 March 2018 (UTC)
- The non-Arch argument has been used plenty in this thread. The solution I mentioned restoring is in NetworkManager#Problems_with_internal_DHCP_client. You reverted both statements I made there, which is something I disagree about.
- There is indeed a fix mentioned in that troubleshooting subsection, but the problem mentioned is different (no ip vs unstable connection) and one would not apply a fix that's intended for a different problem, therefore the solution is incomplete. (and just because the installation section does not mention using dhcpcd does not mean users will not use it and that the potential issue is not worth being posted in troubleshooting. The installation section mentions using dhclient and as far as a standard user knows both dhcp programs serve the same purpose and would not wreak havoc. Obviously this has caused trouble and is worth mentioning in troubleshooting)
- I (very unintrusively) added this other problem the posted solution fixed and I think this statement should stay regardless, "If you have problems with getting an IP address or experiencing connectivity issues".
- I also mentioned "(and disable Trougnouf (talk) 01:05, 10 March 2018 (UTC) if it is present)" at the end of the paragraph, based on the forum post and my victorious experience with working network, however this may be unrelated as you've mentioned so I plan on testing each configuration to find the exact root cause and properly document it. --
- If restoring these statements after they've been tested/confirmed is something you'd accept (or however/wherever you'd want them worded) then yes let's end this silly discussion. --Trougnouf (talk) 01:10, 10 March 2018 (UTC)
- You are not appreciating the fact that you are not using Arch linux according to Arch linux code of conduct. It is irrelevant here what Anarchy developers claim and whether supposed difference between Arch and Anarchy coveres dhcpcd/dhclient or not. I personally disagree with biases against particular software and favoring another (especially when proponents failed to see difference between dhcpcd.service and dhcpcd@.service). --Mxfm (talk) 05:09, 10 March 2018 (UTC)
- I did further testing and simply doing "systemctl start dhcpcd" does result in loss of connectivity which necessitates disconnecting and reconnecting to the network after a few minutes, therefore it should be disabled in addition to adding dhclient to the NetworkManager config file (the part that's currently documented) with (at least) the eduroam (wpa2-enterprise) network. --Trougnouf (talk) 08:42, 15 March 2018 (UTC)