- Reporting bugs
- Relevant software
- Knowing what wireless driver you use
- Kernel panics/hangs
- Other issues
- Distribution specific notes
- Identifying the bug
- iw event log
- increase debugging in the kernel log
- Reporting bugs in NetworkManager
- Reporting bugs in wpa_supplicant
- Reporting bugs in drivers or mac80211
- When will your kernel issue be fixed ?
Wireless drivers are just one component of the software stack necessary for wireless devices to function. There are also userspace components, namely NetworkManager, wpa_supplicant, Dbus, wireless-tools, wireless-regdb, CRDA, iw and possibly many more (as always, there are lots of options to choose from).
It is best if you to try to determine where the issue is before reporting it since you can then report it to the right place. If unsure you can check out user support IRC channel and ask there.
Knowing what wireless driver you use
If you are unsure of which wireless card you have or which driver you are using, run the lspci -k command in a terminal (note that the -k option for lspci is available in version 3.0.0 or later). Some example output follows:
$ lspci -k | grep -A3 "Network controller" 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) Kernel driver in use: iwl3945 Kernel modules: iwl3945
Kernel panics are kernel bugs, and should be reported immediately. Kernel hangs are usually kernel bugs as well and should be reported too. If you can, you should try to determine whether the bug persists in the latest stable linux release.
Please also report other issues, for example when things are not working correctly. In this case, you are encouraged to try out the latest wireless-testing git tree or the latest compat-wireless snapshot.
If you are not sure if your issues is driver or userspace specific consider asking on our user support IRC channel for help.
Distribution specific notes
Some distributions have additional, specific information. Check there first:
Identifying the bug
In order to help developers help you better you can do some work on your part to try to narrow bugs down better. If you are unsure about where the bug lies you can start by turning off NetworkManager and its attached wpa_supplicant and then try running wpa_supplicant yourself with your own configuration file. NetworkManager keeps its configuration internally and uses Dbus to relay to wpa_supplicant its configuration settings. To try to reproduce a configuration file similar to the one NetworkManager uses you can check the log file used by NetworkManager (/var/log/messages in most some systems) to review the settings used. If you can still reproduce the issue then try using wireless-tools or iw to connect manually. You will only be able to use wireless-tools or iw to connect manually if your wireless connection *does not require* WPA or WPA2. For connections with WPA or WPA2 you *need* to use wpa_supplicant.
To stop NetworkManager use:
# Red Hat based systems sudo /sbin/service NetworkMananger stop # Debian based systems (Ubuntu is one) sudo /etc/init.d/NetworkManager stop sudo killall -TERM wpa_supplicant
iw event log
Please install iw and provide the output of the iw event -t in your bug report. The -t is to add timing information.
increase debugging in the kernel log
We recommended these to be enabled:
CONFIG_MAC80211_HT_DEBUG=y CONFIG_MAC80211_VERBOSE_PS_DEBUG=y CONFIG_MAC80211_VERBOSE_DEBUG=y
If using compat-wireless you can edit config.mk and enable them there. Note that each driver may also have their own respective debug parameters so this could also help but usually it is best to first just use the iw event log and the kernel log to report an issue.
Reporting bugs in NetworkManager
Reporting bugs in wpa_supplicant
You can report bugs in the hostap mailing lists.
Reporting bugs in drivers or mac80211
You should report them on the Linux wireless mailing list.
When will your kernel issue be fixed ?
Understanding how bugs actually get fixed and fixes get propagated through the kernel is important to understanding when and how your specific issue may be fixed upstream. It should also help you as a user understand why using bleeding edge can tend to help accelerate the pace for a bug fix.
Getting fixes in to wireless-testing first
cfg80211, mac80211, or wireless driver bugs will always be fixed first on the wireless-testing git tree. Once a bug is fixed there it will be determined by the developer and community whether the fix is also required for older stable kernel releases, if it is it will undergo the process described below.
Getting fixes in to stable kernel releases
If a patch submitted for inclusion into wireless-testing is a stable fix candidate the patch will be annotated as such prior to submission with a note towards the bottom of the patch commit log for stable:
Once the patch gets merged onto John's tree, John Linville (wireless maintainer) will determine whether or not the patch also fixes an issue on Linus' tree; and if so it gets submitted to David Miller (networking maintainer) so that David can then propagate the fix to Linus. Once the patch gets merged onto Linus' tree an e-mail will be sent to firstname.lastname@example.org and the patch will be either directly queued or ported for review on the stable-review mailing list. If no objections are raised the patch then gets merged onto the respective stable kernels.
Getting the fix in your Linux distribution
Linux distributions which make official tagged release stick to a series of stable kernels for each release. This is contrary to rolling distributions which always just keep on the latest and greatest all the time. Distributions like Ubuntu, Debian, RHEL, Fedora are not rolling distributions, distributions like Gentoo and Arch are rolling distributions. Non-rolling distributions usually stick to supporting only one kernel per tagged release. The kernel they pick for use on a release is based on the date of the targeted release. Updates to the kernel will be made on a Linux distribution once a new stable kernel release with a newer extraversion is released. The extraversion is the last number in a 4 series number release, so in 188.8.131.52 the extraversion would be 2.
When a fix cannot be propagated to stable releases
Not all fixes will be propagated to stable releases of the Linux kernel. It is better to understand what fixes will be merged onto stable kernel releases than to consider which fixes will not. Fixes which will be accepted for stable kernel releases will vary but a general rule of thumb is:
- Kernel oops
- Security flaws
- Memory leaks
- Regressions (issues introduced into newer kernels which did not exist in older kernel releases)
- Critical fixes
What fits into a Critical fix category are left to the judgment of the subsystem maintainer. Unfortunately for users the reality of this model is some minor fixes which can help a user out on a stable kernel will not be merged into new stable kernel release, but this is also why new kernels are always encouraged, and also why we have come up with bleeding edge compat-wireless releases and stable compat-wireless releases.