A Good Bug Report...

...is about one specific problem, and includes the following things:

• your distribution name and version
• your kernel version

  • running the command uname -r prints out your kernel version

• your network device's brand and model, including the hardware revision (usually something like "A1" or "B2")
• your network device's hardware IDs

  • if it's a USB device, include the output of lsusb -v

  • if it's a PCI or CardBus device, include the output of lspci -vn

  • if it's a PCMCIA device, include the output of lspcmcia -v

• the output of the 'dmesg' command from around the time you experienced your problem

• NetworkManager logs (see below)

• wpa_supplicant logs (for wireless and 802.1x connections, see below)

Log File Locations

NetworkManager

Where NetworkManager log output goes varies by distribution:

• Fedora: Run: sudo journalctl -u NetworkManager.service

• Ubuntu: /var/log/syslog
• Others: /var/log/daemon.log or /var/log/NetworkManager.log

NetworkManager uses the 'daemon' syslog facility, so unless your distribution has modified the location of NetworkManager's log output specifically, all the logging will be directed to wherever your distro directs the 'daemon' facility's output.

wpa_supplicant

Supplicant logging is normally directed to /var/log/wpa_supplicant.log. For wpa_supplicant 0.7 and later, this location is controlled by the /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service file.

For wpa_supplicant 0.6, the log location is controlled by the /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service file.

Debugging WiFi Connections

NetworkManager logs the configuration it sends to wpa_supplication in the normal syslog location. That's very important since it tells us what parameters wpa_supplicant will use to connect to the wifi network, and it looks like this:

Apr 27 17:49:43 dcbw NetworkManager[922]: <info> Config: added 'ssid' value 'swedish-chef'
Apr 27 17:49:43 dcbw NetworkManager[922]: <info> Config: added 'scan_ssid' value '1'
Apr 27 17:49:43 dcbw NetworkManager[922]: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Apr 27 17:49:43 dcbw NetworkManager[922]: <info> Config: added 'psk' value '<omitted>'
Apr 27 17:49:43 dcbw NetworkManager[922]: <info> Config: added 'proto' value 'WPA RSN'
Apr 27 17:49:43 dcbw NetworkManager[922]: <info> Activation (wlan12) Stage 2 of 5 (Device Configure) complete.
Apr 27 17:49:43 dcbw NetworkManager[922]: <info> Config: set interface ap_scan to 1

Next, to debug most low-level wifi problems like failure to connect or dropped connections, we need to get debug logging from the supplicant.

Debugging wpa_supplicant 0.7 and later

If your /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service file contains "-f /var/log/wpa_supplicant.log" on the Exec= line, then you can execute the following commands in a terminal to get verbose debug logging sent to /var/log/wpa_supplicant.log:

sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true

sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump"

That's it! Reproduce the problem and then send /var/log/wpa_supplicant.log to the NetworkManager developers. Be aware that this may include some personal and network-related information, so if you attach this log to a bug report you'll want to make it private, and if you email the log you may not want to send it to a mailing list.

Rebooting will reset the supplicant log level, but if you want to turn it off manually, you can run the following command:

sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"info"

These instructions rely on wpa_supplicant being built with CONFIG_CTRL_IFACE_DBUS_NEW. If only the old D-Bus control interface has been enabled at the supplicant's build time (like on Red Hat Enterprise Linux 6), try:

sudo dbus-send --system --print-reply --dest=fi.epitest.hostap.WPASupplicant /fi/epitest/hostap/WPASupplicant fi.epitest.hostap.WPASupplicant.setDebugParams int32:0 boolean:true boolean:false

and to return to normal:

sudo dbus-send --system --print-reply --dest=fi.epitest.hostap.WPASupplicant /fi/epitest/hostap/WPASupplicant fi.epitest.hostap.WPASupplicant.setDebugParams int32:2 boolean:false boolean:false

Debugging wpa_supplicant 0.6 and earlier

You'll need to modify the D-Bus service activation file to enable debugging and the log output to a file:

• Modify /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service file and add "-dddt" to the end of the Exec= line so that the file looks like this:

[D-BUS Service]
Name=fi.epitest.hostap.WPASupplicant
Exec=/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log -dddt
User=root

• Stop NetworkManager

• killall -TERM wpa_supplicant
• rm -f /var/log/wpa_supplicant.log

• Start NetworkManager

• reproduce your problem

• grab /var/log/wpa_supplicant.log and send that and the NetworkManager logs to the developers

Hidden networks

Hidden networks do not broadcast their SSID. This is false security. Don't use them if you can help it. Even Cisco says so:

Q. If I disable SSID broadcast, can I achieve enhanced security on a WLAN network?

A. When you disable SSID broadcast, SSID is not sent in Beacon messages. However, other frames such as, Probe Requests and Probe Responses still have the SSID in clear text. So you do not achieve enhanced Wireless security if you disable the SSID. The SSID is not designed, nor intended for use, as a security mechanism. In addition, if you disable SSID broadcasts, you can encounter problems with Wi-Fi interoperability for mixed-client deployments. Therefore, Cisco does not recommend that you use the SSID as a mode of security. 

In any case, people have to live with hidden SSID networks. There are a few things you can do to figure out if your driver is at fault or something else:

• stop NetworkManager and killall -TERM wpa_supplicant

• rmmod your device's kernel driver, and modprobe it again
• ifconfig wlan0 up (use your wifi card's device name of course)
• iwlist wlan0 scan (use your wifi card's device name, which you can find from 'iwconfig')
  • if your device reports an error here, your driver is broken
• look for your AP's MAC address (called a BSSID)

• if you can see your AP's BSSID but not the SSID, then NetworkManager can match up the BSSID and the SSID with the stored list in GConf.

• if you do not see your AP's BSSID, try running the 'iwlist wlan0 scan' command again; not every AP is found every scan

If that still doesn't show your AP, chances are your driver is not working correctly. There is one more thing to try.

• iwlist wlan0 scan essid <your AP's SSID>

• if that doesn't show your AP, try it one more time

If that still doesn't show your AP, *including the SSID*, then your driver is broken or your AP may need a reboot. At this point, only kernel driver debugging will help fix the problem. If you are using a 'staging', vendor, or binary driver, chances are your driver is broken and it's unlikely to be fixed because it's not one of the upstream official kernel drivers.

Other NetworkManager Debugging

If your problem isn't wifi related, or you just want to get some more debugging information out of NetworkManager, you can tell NM to change it's log level dynamically using dbus-send. NM has both log levels and log domains; the level controls how verbose NM's log output will be. Domains control what parts of networking NM emits log messages for. For example:

sudo dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.SetLogging string:"debug" string:""

will result in verbose debugging information directed to normal NetworkManager log locations. In this request, the first argument is the log level, and the second is the log domain. Leaving either of the two arguments blank (ie, an empty string) will leave that argument unchanged. See 'man NetworkManager.conf' for a list of available log domains.

To turn off debug logging, run the dbus-send command referenced above, except use 'info' as the log level instead of 'debug':

sudo dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.SetLogging string:"info" string:""

Debugging NetworkManager 0.8 and 0.9 3G connections

NetworkManager 0.8 and later use ModemManager for 3G device control. To get logs from modem-manager, we use the "--debug" option.

• Stop NetworkManager

• killall -TERM modem-manager
• modem-manager --debug

• start NetworkManager again

NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon

• reproduce the problem

• send the modem-manager and NetworkManager logs to the developers

Debugging NetworkManager 0.7.x 3G connections

(NetworkManager 0.8 uses modem-manager so this does not apply)

• Stop NetworkManager

• run NetworkManager like so:

NM_SERIAL_DEBUG=1 NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon

• reproduce the issue

• Copy the NetworkManager logging output and send it to the developers

  • If you use a PIN to unlock the SIM, replace the PIN with XXXX before sending

Debugging NetworkManager-openvpn

• with version >= 1-2: edit /usr/lib/NetworkManager/VPN/nm-openvpn-service.name and set supports-multiple-connections=false (revert the change later)

• killall -TERM nm-openvpn-service
• in a root terminal, run

/usr/libexec/nm-openvpn-service --debug

• start your VPN connection
• reproduce the problem
• send the nm-openvpn-service output to the developers

Debugging NetworkManager-vpnc

See #Debugging_NetworkManager-openvpn

Debugging NetworkManager-pptp

See #Debugging_NetworkManager-openvpn