User Tools

Site Tools


en:users:drivers:iwlwifi:debugging

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
en:users:drivers:iwlwifi:debugging [2016/11/01 06:26]
Emmanuel Grumbach [Prints]
en:users:drivers:iwlwifi:debugging [2019/10/10 05:44]
Luca Coelho [Prints] updated line number of debug bitmap
Line 1: Line 1:
 ====== Bugs and support ====== ====== Bugs and support ======
 +
 +===== Before you contact us... =====
 +We try to give the best support we can with the best response time possible. We also don't have several levels of support, by contacting us, you contact the developers who are also busy with other tasks. Before reaching out to us, please make sure you have a supported Intel Wi-Fi device and that it is enabled. Many request are for problems in the rfkill area where the platform pulls the rfkill signal preventing us from doing anything.
 +
 +If you see that Wi-Fi is hard blocked like in:
 +
 +<​code>​
 +3: phy0: Wireless LAN
 +  Soft blocked: yes
 +  Hard blocked: yes
 +</​code>​
 +
 +you can blacklist the WMI module and see if that helps. The name of the WMI module will vary depending on the OEM. A simple lsmod | grep wmi should give you a hint of what module to blacklist.
  
 ===== How to report? ===== ===== How to report? =====
Line 12: Line 25:
 ==== Prints ==== ==== 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. ​+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#​n129|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. Please don't add debug level unless instructed to do so. Adding more prints typically adds useless information.
  
Line 23: Line 36:
  
 <​code>​sudo trace-cmd record -e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg</​code>​ <​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.+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/​pub/scm/​linux/​kernel/​git/​stable/​linux.git/​tree/​drivers/​net/​wireless/intel/​iwlwifi/​Kconfig#​n139|CONFIG_IWLWIFI_TRACING]] must be set. 
 + 
 +**//Note: you must not remove the iwlwifi kernel module while tracing is running. You need to stop the tracing first!//​** 
 + 
 +==== 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 Wi-Fi client. To do so there are several options: 
 +  * Disable Wi-Fi 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 Wi-Fi 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 ==== ==== Firmware Debugging ====
Line 63: Line 101:
 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. 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. 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.
  
Line 76: Line 113:
 In this case, please copy the full dmesg output since there may be data before and after this message that can be helpful. 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 customized ​version.+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 we usually need more information than the data provided by a release version of the firmware. When you report ​bug, please use a debug firmware  
 +from the list below. This will allow to include more data in the dump at the cost of extra PCI transactions:​ 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-3160-17.ucode.gz|debug firmware ​version ​for 3160}} 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-7260-17.ucode.gz|debug firmware version for 7260}} 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-7265-17.ucode.gz|debug firmware version for 7265}} 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-7265d-29.ucode.gz|debug firmware version for 7265D}} 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-3168-29.ucode.gz|debug firmware version for 3168}} 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-8000C-36.ucode.gz|debug firmware version for 8260}} 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-8265-36.ucode.gz|debug firmware version for 8265}} 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-9000-pu-b0-jf-b0-43.ucode.gz|debug firmware version for 9000}} 
 + 
 +{{en:​users:​drivers:​iwlwifi:​iwlwifi-9260-th-b0-jf-b0-43.ucode.gz|debug firmware version for 9260}} 
 ==== Privacy aspects ==== ==== 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.  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. 
  
-Please don't attach the firmware dumps to public bug trackers (such as bugzilla), but send it privately through email. ​We recommend you encrypt the data using the iwlwifi developers'​s PGP keys: Emmanuel Grumbach (6E363201), Johannes Berg (7BF9099A) and Luciano Coelho (1A3CC5FA). ​ For instance:+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:
  
-<​code>​gpg --encrypt -r 6E363201 ​-r 7BF9099A ​-r 1A3CC5FA ​<​file_to_encrypt></​code>​+  * Emmanuel Grumbach (18D075865D915B5E386F660F2D0B96FE6E363201);​ 
 +  * Johannes Berg (C0EBC440F6DA091C884D8532E0F373F37BF9099A);​ 
 +  * Luciano Coelho (1772CD7E06F604F5A6EBCB26A1479CA21A3CC5FA). 
 + 
 +For instance: 
 + 
 +<​code>​ 
 +gpg --recv-keys C0EBC440F6DA091C884D8532E0F373F37BF9099A 1772CD7E06F604F5A6EBCB26A1479CA21A3CC5FA 18D075865D915B5E386F660F2D0B96FE6E363201 
 +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. 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.
en/users/drivers/iwlwifi/debugging.txt · Last modified: 2022/05/30 08:07 by Johannes Berg