Peppermint | Linux OS Community Forum
It is currently Sun Mar 29, 2020 3:09 pm

All times are UTC - 5 hours [ DST ]

Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: [One][Ice][Two] Wireless Troubleshooting Part 2 - Resolving
PostPosted: Thu May 27, 2010 3:39 pm 
User avatar

Joined: Thu May 20, 2010 8:56 am
Posts: 2132
This is the second, more advanced part of the wireless troubleshooting guide whose first part is here. It is essential to read the first part first if you are new to troubleshooting WiFi connections, since it explains how to obtain diagnostic data and research the problem. This document deals with ways of going about actually making the device work.

Troubleshooting procedure

It is possible that simply researching on Google will either confirm that a device is simply not natively compatible with the Linux kernel (no module is available for it, in which case it may be possible to get the device working with win32 drivers - see below), or provide a tutorial on how to get a known problematic device working. Any results found on these boards, Mint, or the Ubuntu boards may be useful on Peppermint OS. Results found on Debian community pages may also be worth considering. If results are found from a different distribution, for example Fedora Core or Mandriva, then it might be worth asking for advice here before attempting to reproduce any steps provided. This is because file system layouts, commands and configuration settings can vary from distribution to distribution.

Failing that, it is worthwhile taking a systematic approach to troubleshooting the problem and attempting to come to a solution.

The following flowchart is intended to provide some guidance as to possible steps to take. It is worth reading this as a guide and not feeling that it must be followed to the letter. Wifi networking is complex and in some cases the flowchart is not up to the task. For example, a Broadcom card might be made to work using win32 drivers using ndiswrapper (not evident if following the flowchart strictly). It pays to take a holistic view of the issue at hand.

The flowchart should just about print on a single side of A4.

Click on the thumbnail to see the whole thing. AP refers to Association Point - this is the target router or hub which has (we're assuming... ;) ) a connection to the Internet which we are trying to connect to. From hereon out the acronym NIC will also be used to refer to the wifi Network Interface Card. I also provide this link to the OpenOffice drawing file of the original, and a link to this pdf of the same.


WEP/WPA hex passkeys, passwords and pre-shared passphrases

It is naturally important that network manager be given the correct passphrase or alpha-numeric hex key to be able to connect to an encrypted network. It is also important that the appropriate option be chosen in network manager's drop down box. If the flowchart leads to this resolution, right click on the network manager applet's icon and select "edit connections", select the appropriate connection and navigate to the security tab:


If in doubt about what option to choose, contact the ISP providing the connection, the router manufacturer, or the network administrator. Also feel free to ask in the networking forum.

Physical problems

It is entirely possible that wireless network problems be caused by adverse physical conditions. This can include being on the same channel as many other networks in the area, being too far away from or too close to the AP, physical obstructions between the adaptor and the AP: even strong winds have been known to cause intermittent wifi connections.

Just because the NIC works at a given location under given conditions with another driver on a different OS does not necessarily mean that it will work as well with Linux native drivers, and vice versa. It may help to move the location of the NIC or the AP, or change the channel the AP broadcasts on to avoid interference from other APs in the area or other devices (bluetooth, mobile telephony, 3G). Changing the channel of the AP depends on it alone; refer to the relevant documentation for guidance, or if necessary ask on the networking board in the hope that someone will have a similar device.

Hidden APs

Some network administrators "hide" the AP, meaning that it is not normally visible when the NIC scans for it. This will mean that it is not listed as normal by the network manager applet. If this is the case, obtain the BSSID (the name of the AP), and the type of encryption used, from the network administrator of the AP to which the connection needs to be made. These details may then be given to network manager by left clicking on its panel icon and selecting "Connect to hidden wireless network".

Conflicting kernel modules

The current writer is in a good place to explain this since it is a fix I do to get wireless working on his system. I do it at install time, i.e. editing the appropriate file on the hard drive while still in the live environment before rebooting.

The owner of a NIC which needs the rt2870sta driver to establish a good connection, I found out that the rt2x00usb driver and its dependencies load in automatically, and cause the device to be available in network manager but no APs to be visible.

To test the information retrieved from researching on the Internet (see above), the writer removed the rt2800usb driver and its dependencies from the kernel at runtime by opening LXTerminal and entering:

sudo rmmod rt2800usb
sudo rmmod rt2x00usb
sudo rmmod rt2x00lib

And loaded the rt2870sta driver using modprobe:

sudo modprobe rt2870sta

It may have been necessary to bring the device up manually:

sudo ifconfig ra0 up

The device was now available through the network manager applet and APs were visible to connect to.

This is just an example, but a similar procedure should be applicable to any situation where a conflicting module to the one needed by the device is being loaded in by the default system. Researching the problem using Google and some common sense may very well lead to exact commands for a given user's actual device.

If such steps work, then they may be made permanent by blacklisting the unwanted modules. This is achieved by editing the /etc/modprobe.d/blacklist.conf file. This needs to be done as root (i.e., open the folder in file manager as root by using the option from the tools menu, and then open the file in leafpad and edit it). Simply add the names of the modules that should not be loaded in. The end of my blacklist file reads, as an example,

# Use rt2870sta for ralink
blacklist rt2800usb
blacklist rt2x00usb
blacklist rt2x00lib

It might also be necessary to add the name of the module that needs to be loaded in to the end of /etc/modules. Simply append the exact name of the module to the end of the list. These steps should mean that the necessary module(s) are loaded in at boot time and the wifi card will be ready for use at login with no need for further intervention.

Firewalls / Mac filtering / Router issues

There is a possibility that the NIC is unable to connect to a visible AP because of a firewall on the AP, or that it is filtering MAC addresses. In these instances it is worth resetting the AP to its default settings or consulting with the network administrator.

A very few accounts have been made of certain routers not working well with NICs working with Linux drivers, but this is rare and difficult to verify as such reports are often conflicting.

BIOS settings - onboard wlan on laptops set to off

Laptops with onboard wireless cards frequently have an option to shutdown the radio transmitter, in the interests of power saving as well as safety during air transportation.

The state of the radio transmitter may be controllable via the laptop's BIOS; common options are "last state" (i.e., the state it was in at last shutdown), "always off" and, hopefully, "always on". This last option may not be available, however, and in certain cases relies upon a win32 application to control it, usually via the pushing of a special button somewhere on the laptop case. If this is the case then the best hope is to boot in to the system under Windows and switch the transmitter on using this software, and ensure that the BIOS is set to set the transmitter to "last state" for use with Linux.

The Broadcom firmware cutter

Broadcom wireless NICs tend to appear quite a lot in Linux support forums as they pose particular difficulties due to their firmware. Some manual intervention is often necessitated to get them to work natively or with ndiswrapper and win32 drivers (see below). The current writer is not an owner of a Broadcom NIC and I am therefore unfortunately unable to test these solutions on Peppermint OS. However, I can provide links to the Linux Mint wiki page on configuring such a card with the firmware cutter here, and Ubuntu's community page on Broadcom NICs here.

Win32 drivers and mintWifi

mintWifi documentation is located here.

If there is no kernel module available for a given NIC, or if the current kernel module does not provide appropriate functionality, then all hope is not lost. It may be possible to install and use the win32 drivers that usually come packaged with a NIC, typically on an installation CD. To do this, obtain, using a wired connection, or an alternative connection, mintWifi from the repositories. Note that mintWifi depends on ndisgtk, ndiswrapper-utils-1.9, and ndiswrapper-common.

Note that the mintWifi package provides win32 drivers for about forty cards. If you wish, and your card is supported you can navigate to /usr/lib/linuxmint/mintWifi/drivers/i386/yourDriverFolder and select the .inf file from there.

A quick note about 64 bit drivers - they will not work on Peppermint OS since Peppermint OS uses the 32 bit kernel. This applies regardless of whether the machine is 32 bit or 64 bit. Only use drivers from the i386 folder, or, if installing using a CD, the win32 drivers and not the 64 bit ones.

If obtaining win32 drivers from elsewhere, it might be best to have the win32 drivers available in your home folder, copied either from the disk supplied with the hardware or downloaded from the website. They should be unpacked if they were supplied in a .zip or some other archive; use Accessories -> Xarchiver or your favourite archive software for this.

Either way, installing mintWifi provides a launcher named "Windows Wireless Drivers" in the Preferences menu.

Click on the green 'Install New Driver' button and navigate to the .inf file somewhere in the driver folder. In most cases the software will take care of the rest of the installation, including load the ndiswrapper module. If successful, you will see the device listed in mintWifi's main pane, and 'Hardware Present: Yes' will be underneath. Note that it has been reported that, on occasion, mintWifi will mistakenly report that the hardware is not present even when it is. It is best to check with iwlist for authoritative information.

Once installed, the device should hopefully work as expected. Once this is the case, rename a file to make it futureproof:

sudo mv /etc/modprobe.d/ndiswrapper /etc/modprobe.d/ndiswrapper.conf

Write an alias for the default wireless device into the module configuration file such that the kernel module is loaded automatically when the interface is used:

sudo ndiswrapper -m

And finally add a line to /etc/modules

sudo nano /etc/modules

And add the line


to the bottom. The device should now work when it is plugged in and / or Peppermint OS is started.


The letters b, g and n refer after 802.11 refer to different versions of the wifi standard. The letters increment over time, with b offering the least performance and n the most.

In any event, while the standards are all supposed to be backwards compatible, it is known that some network cards are not. Older models of laptop with integrated b cards have been known to struggle with newer routers which are set to g unless explicitly configured to b. It is best to have the AP and the NIC set to the same standard if there is a suspected problem.

Submitting help requests and bug reports

If it has gotten to this stage then commiserations are in order. However, all is not lost.

It is better to seek support before submitting a bug report. Many bug reports are duplicates of known problems, and many of these have known workarounds.

When seeking support, provide some information about your NIC, your AP, the steps you have already taken and the exact nature of the problem (i.e.; device not showing up in Network Manager, no APs listed, can't connect to AP...). Previous stanzas of this tutorial have covered how to obtain this information.

If after seeking support there is no help to be found, it might be worth consulting's user pages for obtaining further support and submitting a bug report against the driver if it is at fault, or alternatively report the issue to the GetSatisfaction problems tracker. Again, it is helpful to provide as much information as possible that is relevant to the wifi issue - NIC, kernel module, AP details and steps taken to try to resolve the issue as well as the precise nature of the difficulty. Further, when reporting a bug, users are asked to please search to find out if their issue has already been reported. The majority of bugs on trackers are duplicates of known issues, and it consumes valuable developer time to identify these bugs as duplicates and move on.

If in doubt, post on the network board of these forums. We hope that we can help you to resolve whatever wifi networking problem you may have.



Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 5 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

Powered by php B.B. © 2000, 2002, 2005, 2007 php B.B. Group
Template made by DEVPPL