Difference between revisions of "Talk:Wireless network configuration"

From ArchWiki
Jump to: navigation, search
(Splitting the page: new section)
(Modules - Generic: close)
 
(107 intermediate revisions by 17 users not shown)
Line 1: Line 1:
== iwlist wlan0 scanning syntax ==
+
== <s>Modules - Generic</s> ==
  
In section "https://wiki.archlinux.org/index.php/Wireless_Setup#Access_point_discovery" is the shell command "iwlist wlan0 scanning" mentioned. "iwlist scan" will do in most cases, and is even without system dependent interface names. (Also, its at least 4 characters shorter, depending on system configuration, and in this respect more according to the arch way than the current version.) -- [[User:Scr|Scr]] ([[User talk:Scr|talk]]) 12:26, 5 April 2013‎ (UTC)
+
If you found that you wireless permanently disconnects and you're using NetworkManager try to run:
:Similar to [[Core Utilities#ip|ip]], all objects may be written in full or abbreviated form, as long as it's unambiguous. For example, following commands are equivalent: {{ic|iwlist wlan0 scanning}}, {{ic|iwlist wlan0 scan}}, {{ic|iwlist wlan0 s}}. For good readability, I'd definitely not use the shortest {{ic|s}}. As {{ic|iwlist --help}} yields the full form {{ic|scanning}}, I think it's better to keep it that way. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:00, 1 August 2013 (UTC)
+
echo "options mac80211 probe_wait_ms=3000" > /etc/modprobe.d/wireless.conf -- 19:40, 23 September 2014‎ NickNill
  
== wpa_supplicant.conf ==
+
:Moved to talk as it doesn't explain what this does, nor how it fits in the article. Possibly belongs in [[Wireless_network_configuration#Random_disconnections]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:55, 23 September 2014 (UTC)
  
I installed Arch Linux in December 2012 and my wpa_supplicant.conf file is at /etc/wpa_supplicant/wpa_supplicant.conf , so I would suggest updating this page to reflect that.  [[User:DavidEGrayson|DavidEGrayson]] ([[User talk:DavidEGrayson|talk]]) 23:17, 16 December 2012 (UTC)
+
== wireless_tools ==
:That is intentional in order not to change the original .conf which is really good reference documentation in itself. Explanation for it you find in the wpa_supplicant wiki here. The idea is you create a new /etc/wpa_supplicant.conf and work with that. Since all wpa_supplicant calls mentioned in the wiki address the /etc version, its fine in my view. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:27, 17 December 2012 (UTC)
+
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]]? [[User:Pid1|Pid1]] ([[User talk:Pid1|talk]]) 15:11, 3 October 2015 (UTC)
  
==Mention modprobe -l==
+
:Many sections in [[Wireless_network_configuration#Troubleshooting]] still suggest only iwconfig commands. We need to find equivalent iw options first... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:21, 3 October 2015 (UTC)
Does anybody else besides me think that it would be helpful to mention modprobe -l to get a list of loaded modules/drivers and that ath9k is already included in the kernel at the beginning of ''First steps'' or ''Drivers and Firmware'' section? In my case (I have a Thinkpad x61) I didn't have to install any additional drivers, so I could proceed immediately to Manual setup and everything worked perfectly.
 
<br>--[[User:Bhobbit|Bhobbit]] 01:03, 7 June 2009 (EDT)
 
  
== Overall article readability (notes and split) ==
+
== "your key" ==
There is no doubt this article is very rich, but I find it a bit messy overall.
 
At first sight, the newcomer may think managing wireless is a real odyssey, whereas it may be 2 simple steps for most users.
 
* More than 50% of the article is dedicated to specific drivers installation. Perhaps it would be worth moving the whole section to a dedicated page, leaving only generic install guidelines here.
 
* I've found 21 ''Note'' templates. Too much imho, it makes different sections and code lines harder to distinguish, and thus diminishes article's overall readability. Some of them definitely do not deserve a template, they should be written as is.
 
  
Still I won't say there is no doubt these 2 changes would make the article really better. So feel free to discuss!
+
What is ''my key''? [[Wireless_network_configuration#Association]] --[[User:Kete|Kete]] ([[User talk:Kete|talk]]) 00:38, 11 March 2016 (UTC)
  
-- [[User:Ambrevar|Ambrevar]] ([[User talk:Ambrevar|talk]]) 10:27, 6 July 2012 (UTC)
+
:I believe it is the security password configured on the router. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 12:47, 11 March 2016 (UTC)
  
== Auto-connect if dropped or changed location Wicd ==
+
== Setting regulatory domain ==
  
I tested this with wicd and this didn't work (with my raspberry pi and an ASUS USB-N10 adaptor). Once the connection was dropped the device didn't even search for other networks (the light at the adaptor didn't blink).
+
In the section ''Respecting the regulatory domain'' in my opinion the following information should be added:
  
I now tried again with netcfg and that works like a charm, so it has nothing to do with my hardware. Are there others who are experiencing the same problem?
+
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.
<br>-- [[User:Warddr|Warddr]] ([[User talk:Warddr|talk]]) 15:17, 22 August 2012 (UTC)
+
As far as I unterstand these information are only retrieved, if the PC is associated with the access point.
 +
For details see: [https://wireless.wiki.kernel.org/en/developers/regulatory/processing_rules] (subsection: ''Country IE processing'')
  
== Splitting the page ==
+
{{unsigned|15:21, 7 May 2016‎|Aluser1137}}
  
Regarding the note on top of the page, what about moving [[Wireless_Setup#Part_I:_Identify_Card.2FInstall_Driver]] to separate page, for example [[Wireless Setup/Hardware Support]]? That page would be focused on troubleshooting connection problems, installing drivers problems, and hardware support in general. Perhaps it would even make sense to merge some short dedicated pages into this one. What do you think? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:13, 1 August 2013 (UTC)
+
== rtl8812au/8814au/8821au ==
 +
 
 +
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 8812au and we may be able to correctly maximise power of these dongles.
 +
* 8814au: this is 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?
 +
 
 +
--[[User:Zeb|zeb]] ([[User talk:Zeb|talk]]) 10:57, 6 September 2017 (UTC)

Latest revision as of 13:58, 18 September 2017

Modules - Generic

If you found that you wireless permanently disconnects and you're using NetworkManager try to run: echo "options mac80211 probe_wait_ms=3000" > /etc/modprobe.d/wireless.conf -- 19:40, 23 September 2014‎ NickNill

Moved to talk as it doesn't explain what this does, nor how it fits in the article. Possibly belongs in Wireless_network_configuration#Random_disconnections -- Alad (talk) 17:55, 23 September 2014 (UTC)

wireless_tools

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)

"your key"

What is my key? Wireless_network_configuration#Association --Kete (talk) 00:38, 11 March 2016 (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: [1] (subsection: Country IE processing)

—This unsigned comment is by Aluser1137 (talk) 15:21, 7 May 2016‎. Please sign your posts with ~~~~!

rtl8812au/8814au/8821au

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:

  1. 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).
  2. 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.
  3. 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 8812au and we may be able to correctly maximise power of these dongles.
  • 8814au: this is 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?

--zeb (talk) 10:57, 6 September 2017 (UTC)