Linux Wireless

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Bugs and support ======

===== How to report? =====
Issues can be filed in [[http://bugzilla.kernel.org|kernel's bugzilla]]. Make sure to add [[mailto:linuxwifi@intel.com|linuxwifi@intel.com]] to the bug.
Always attach the kernel log to your reports:
<code>dmesg > dmesg.log</code> and attach dmesg.log to the bug.
Please also add the firmware version:
<code> ethtool -i wlan0 | grep firmware</code>
Note: the interface name (here wlan0) can vary between distributions.

===== How to debug? =====
==== Prints ====

The simplest way to provide minimal output is to dump your kernel log: dmesg. Sometimes we will ask for logs from the supplicant too - they typically land in syslog. iwlwifi can print more data to the kernel log if asked to: this is controlled by the debug module parameter. This is a [[https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/intel/iwlwifi/iwl-debug.h#n143|bitmap]]. To see more debug prints, [[https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/intel/iwlwifi/Kconfig#n105|CONFIG_IWLWIFI_DEBUG]] must be enabled. 
Please don't add debug level unless instructed to do so. Adding more prints typically adds useless information.

==== Tracing ====

Another (more powerful) way to debug iwlwifi is to use tracing: 

<code>sudo trace-cmd record -e iwlwifi</code>
We will typically ask for more switches: 

<code>sudo trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg</code>
This records all the data that goes from and to the firmware. The output is a file: trace.dat which you can compress prior to sending. To enable tracing, [[https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/iwlwifi/Kconfig#n130|CONFIG_IWLWIFI_TRACING]] must be set.

==== Air sniffing ====
Your Intel device can act as a sniffer (which is also referred to as "monitor mode"). This means that it can record all the packets being sent over the air by all the other devices including your Access Point. When acting as a sniffer, your device cannot be connected to any Access Point or do anything else.
The output of the air sniffing operation is a file with a pcap extension that can be parsed by the [[https://www.wireshark.org|Wireshark]] program.
=== How to get a sniffer capture with your Intel device ===
In order to put your device in monitor mode and get a sniffer capture, you first need to stop using it as a WiFi client. To do so there are several options:
  * Disable WiFi from the Network Manager GUI and re-enable manually with <code>rfkill unblock wifi </code> This may not work on all the distributions.
  * Disable the Network Manager and kill the wpa_supplicant<code>sudo service NetworkManager stop
sudo killall wpa_supplicant</code>

Then you need to put it in monitor mode:
<code> sudo iw wlan0 set type monitor </code>

After that, you can bring the interface up again and set the frequency (taking channel 1 as an example but you should check what frequency you want to listen to):
<code>sudo ifconfig wlan0 up
sudo iw wlan0 set freq 2412</code>

Then you can start the capture:
<code>sudo tcpdump -i wlan0 -w capture.pcap</code>
This file can be opened by [[https://www.wireshark.org/|Wireshark]] and sent for analysis by our developers. Note that this file can be fairly large if you capture a lot of traffic, but it can be compressed very efficiently.
=== How to put your WiFi device back in normal client mode ===
In order to get your device back in a regular client mode, you can either reboot or start the NeworkManager again:
<code>sudo service NetworkManager start</code>

==== Firmware Debugging ====

Note that we no longer provide support for the firmware of the devices using iwldvm.

=== How to provide information to debug the firmware? ===
Getting data from the firmware can often provide a lot of information, especially when the traffic is being stalled, latency is high, queues are stuck etc.. Here is how to do so. This is working starting kernel 3.19.

First you'll need to allow DEV_COREDUMP by setting CONFIG_ALLOW_DEV_COREDUMP to Y.
Then, you'll need to create a core dump. This can be done by:

<code>echo 1 > /sys/kernel/debug/iwlwifi/0000\:0X\:00.0/iwlmvm/fw_dbg_collect</code>
(Check what is the X for your system)

You can now get the data from the devcoredump device and dump to a file:

<code>cat /sys/devices/virtual/devcoredump/devcdY/data > iwl.dump
echo 1 > /sys/devices/virtual/devcoredump/devcdY/data</code>

(Y is incremented each time)

The easiest is to define a udev rule to dump the data automatically as soon as a dump is created:

<code>SUBSYSTEM=="devcoredump", ACTION=="add", RUN+="/sbin/iwlfwdump.sh"</code>
You'll typically have to paste this into a new file called /etc/udev/rules.d/85-iwl-dump.rules.
This location can vary between distributions.

/sbin/iwlfwdump.sh can simply be:
<code>
#!/bin/bash

timestamp=$(date +%F_%H-%M-%S)
filename=/var/log/iwl-fw-error_${timestamp}.dump
cat /sys/${DEVPATH}/data > ${filename}
echo 1 > /sys/${DEVPATH}/data
</code>

This way, each time a dump is created it will automatically land on your file system.  Remember to make the /sbin/iwlfwdump.sh file executable (i.e. ''chmod a+x /sbin/iwlfwdump.sh''), so that the udev rule can execute it, otherwise it won't work.

To debug the firmware you'll typically need a customized version of it. This customization depends on the bug you are facing.
Starting from 4.1, we can trigger firmware dumps when issues occur (e.g. when the association fails) this again requires a customized firmware. In that case, the developer working with you will let you know and you won't have to trigger the dump yourself using fw_dbg_collect debugfs hook.

=== Firmware crashes ===

When the firmware crashes, you'll see a message like this: 

<code>iwlwifi 0000:01:00.0: Microcode SW error detected.  Restarting 0x82000000.
[snip]
iwlwifi 0000:01:00.0: Loaded firmware version: XX.XX.XX.XX
iwlwifi 0000:01:00.0: 0x0000090A | ADVANCED_SYSASSERT</code>
In this case, please copy the full dmesg output since there may be data before and after this message that can be helpful.

In case of a firmware crash or queues being stuck, a dump will be automatically created. If you have the udev rule in place, you'll see the dump on your file system. No customization needed in that case, the dump from a regular firmware will already include valuable data, but the firmware team is likely to ask reproduction with a customized version.
==== Privacy aspects ====

By sending the debug logs, you are providing information to Intel such as your email address, peer’s MAC address, and other information.  This information will be used only for the purpose of troubleshooting the issue you are reporting.  Intel is committed to protecting your privacy.  To learn more about Intel’s privacy practices, please visit [[http://www.intel.com/privacy|Intel's privacy site]] or write Intel Corporation, ATTN Privacy, Mailstop RNB4-145, 2200 Mission College Blvd., Santa Clara, CA 95054 USA. 

We recommend you encrypt the data using the iwlwifi developers's PGP keys before you send it via email or attach it to bug trackers:

  * Emmanuel Grumbach (18D075865D915B5E386F660F2D0B96FE6E363201);
  * Johannes Berg (C0EBC440F6DA091C884D8532E0F373F37BF9099A);
  * Luciano Coelho (1772CD7E06F604F5A6EBCB26A1479CA21A3CC5FA).

For instance:

<code>gpg --encrypt -r 18D075865D915B5E386F660F2D0B96FE6E363201 -r C0EBC440F6DA091C884D8532E0F373F37BF9099A -r 1772CD7E06F604F5A6EBCB26A1479CA21A3CC5FA <file_to_encrypt></code>

This will generate a new, encrypted file that you should provide to us.  Any of, and only, these developers will be able to open the file.  Adding the three keys during encryption allows us to respond faster, since we're not restrained by a single developer's availability.
Linux Wireless

User Tools

Site Tools

Page Tools
