Talk:Wireless network configuration
My2c regarding the Check the driver status sub-section:
Check kernel messages for firmware being loaded $ dmesg |grep firmware [ 7.148259] iwlwifi 0000:02:00.0: loaded firmware version 18.104.22.168 build 35138 op_mode iwldvm
The search keyword 'firmware' was not included in the kernel message for my wireless driver. Being new to manual setup I didn't think about the command dmesg, and assumed the output meant my kernel was not loaded. However the previous command lspci -k had indicated it was loaded creating unnecessary confusion.
I suggest the keyword 'firmware' be changed to reflect the output of the earlier test, lspci -k, in order to maintain continuity.
This could take the form of the adopted convention in the note further down the page:
Note: Examples in this section assume that your wireless device is wlan0 to connect to your_essid wifi accesspoint. Replace both accordingly.
Or use man page conventions:
dmesg | grep [kernel driver] // output of #lspci -k
But since I'm a novice, I can't be certain the dmesg output will _always_ include the driver named by lspci on the relevant dmesg line. See also this this poster's attempt at describing his wireless setup. Its thorough, but it also shows the same discontinuity. "iwlwifi" is the kernel driver, but the output from his posted lspci command seems to be truncated and does not include the driver name (in a sea of some unfamiliar commands, parameters, and device/software proper names).
- Thanks for the input and explaining the reasoning. I left the keyword in but expanded the last para accordingly. Have a look , if it is what you mean. The bbs example you link up there is not fully on spot though, because in that case the (brandnew AC) device is not recognised in mainline kernel yet. That would be more a case for the next section Wireless_Setup#Installing_driver.2Ffirmware. How does the firmware of your card show up in the messages? --Indigo (talk) 09:42, 13 September 2013 (UTC)
- OK, you were quicker ;)
- Wireless Setup#Device driver says that "Some wireless chipsets also require firmware", it is possible that the wireless chipset does not require firmware. It is indeed possible that the word "firmware" is not present in the output though a firmware is being loaded. Out of curiosity, what is your chipset, Xtian?
- I've slightly changed the section too: 
- @Xtian: please read Help:Style, your post was not very readable. When quoting part of ArchWiki pages, it is a good idea to copy the code instead of just text to preserve the original formatting. Also remember to sign your posts to talk pages.
- -- Lahwaacz (talk) 10:11, 13 September 2013 (UTC)
We missed a deprecated iwconfig command
Regarding the note in Wireless Setup#Getting an IP address:
autofor the specific device:
# iwconfig wlan0 channel auto
Before changing the channel to auto, make sure your wireless interface (in this case
wlan0) is down. After it has successfully changed it, you can again bring the interface up and continue from there.
iw does not support
auto channel/freq mode. I'm somewhat suspicious about this, I think it is the default behaviour to autoselect the channel/freq of the AP. What do you say, can the note be removed? Or is there other solution?
- Yes, auto sure is the default. I just tried the contrary, i.e. to set a channel with iw and in fact it fails (iwlwifi; ressource busy as response). Nonetheless, pre-selecting a channel on client side definetely is used less and less nowadays. Most use more than one channel anyway with wifi-n. What I would do is move the note down into troubleshooting as a separate point. But I would leave the "iwconfig" commands in the troubleshootng sections for now and not replace them. Rather use iw when the info gets other updates. --Indigo (talk) 14:45, 13 September 2013 (UTC)
- I've moved the note into Wireless_Setup#Failed_to_get_IP_address, thanks for the suggestion. I don't mind the iwconfig commands in troubleshooting section(s) too, updating troubleshooting sections as a whole is very shaky as it is difficult to simulate the same conditions. -- Lahwaacz (talk) 13:01, 14 September 2013 (UTC)
Access point discovery
Wireless_Setup#Access_point_discovery contains outdated information, the values listed there are for iwlist and iw has completely different output.
- ESSID -> SSID: this was simple 
- Quality: iw does not report quality as a percentage, only signal strength
- Encryption key: the value on/off is not reported, but looking at the code of iw I think that the network is encrypted when
capability:line. For example, when there is
capability: ESS Privacy ShortSlotTime (0x0411)in the output of
iw dev wlan0 scan, then the network is encrypted.
- WPA and RSN are apparent blocks, but WEP is not
- Group cipher, Pairwise ciphers, Authentication suites: very clear, need to check available values - it may be useless, we can reword it to allow additional values (the wiki does not have to list all).
This is very shaky because
iw -h says
Do NOT screenscrape this tool, we don't consider its output stable., but I think the update is necessary.
- Yes, that needs update indeed. You are right with the
Privacyas indicator. Good explanation to rephrase it is .
- The encryption reported by iwconfig was never right anyway. If ever, it only worked for wep (sometimes..). --Indigo (talk) 15:01, 13 September 2013 (UTC)