DebuggingNetworkManager

Differences between revisions 25 and 57 (spanning 32 versions)
⇤ ← Revision 25 as of 2008-11-05 11:58:12 →
Size: 6488
Editor: e177171199
Comment:
← Revision 57 as of 2023-06-27 20:21:45 → ⇥
Size: 5239
Editor: hellsworth
Comment: Added brief section on netplan
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Available languages: [[https://wiki.ubuntu.com/DebuggingNetworkManager_it| Italiano]],
Line 3: Line 4:
== Bug Summary ==
= Bug Summary =
Line 11: Line 13:
== A Testcase == = Understanding your bug and getting more information =
Line 13: Line 15:
A good testcase is a step by step instruction to reproduce your bug starting with driver unloaded and NetworkManager stopped.  * There is a lot of debugging information available on the GNOME Live wiki: [[https://wiki.gnome.org/Projects/NetworkManager/Debugging|NetworkManager/Debugging]].
 * You can also take a look at [[http://live.gnome.org/DarrenAlbers/NetworkManagerFAQ|Darren Albers' FAQ]].
 * There is additional information on DebuggingNetworkManager/ReasonCodes for disconnection and network changes available.
Line 15: Line 19:
Kill NetworkManager = Getting debug logs =

You can then follow developers' intructions on a bug report for the exact command line to use; or run it directly as such.

== Getting NetworkManager debug logs ==

By default, the NetworkManager log level is set to info. You can use nmcli to modify the logging level:
Line 17: Line 28:
  sudo killall NetworkManager $ sudo nmcli general logging level DEBUG domains ALL
Line 20: Line 31:
To unload your driver {{{ modprobe -r DRIVER }}}. You do not need to restart NetworkManager to begin seeing debug messages logged to journalctl. You can watch the NetworkManager logs:
Line 22: Line 33:
Then load the driver and start NetworkManager:
Line 24: Line 34:
  sudo NetworkManager $ sudo journalctl -f -u NetworkManager
Line 27: Line 37:
=== Capture Log === == Getting ModemManager debug logs ==

Manually run with debug enabled:

{{{
$ sudo /usr/sbin/ModemManager --debug
$ sudo /usr/sbin/NetworkManager --debug --log-level=DEBUG
}}}

See also [[https://modemmanager.org/docs/modemmanager/debugging/|DebuggingModemmanager]].

You do not need to restart ModemManager to begin seeing debug messages logged to journalctl. You can watch the ModemManager logs:

{{{
$ sudo journalctl -f -u ModemManager
}}}

== Getting wpasupplicant debug logs ==

Change the log level:
{{{
$ sudo wpa_cli log_level debug
}}}

You do not need to restart wpa_supplicant to begin seeing debug messages logged to journalctl. You can watch the wpa_supplicant logs:

{{{
$ sudo journalctl -f -u wpa_supplicant
}}}

== Getting a capture of syslog ==

Mixing and mashing the above is perfectly acceptable as well if you want to see how NetworkManager and other parts of the stack interact together.
Line 33: Line 75:
 tail -n0 -f /var/log/syslog > /tmp/syslog $ tail -n0 -f /var/log/syslog > /tmp/syslog
Line 36: Line 78:
Adding markers is just like adding new lines with an editor that show the triager what happened at what point of time. Adding markers is just like adding new lines with an editor that show the triager what happened at what point of time. You can also do this on the fly as you test with the command {{{logger "[ clicked on wireless network 'ubuntu']" }}}.
Line 43: Line 85:
Line 47: Line 90:
=== Serial Log (Mobile Broadband) === == Handling 3G / modem issues ==

Here are a few extra things that are very helpful to add in case of issues with 3G.

The output of udevadm for tty devices, and output of lsusb:
Line 50: Line 97:
# become root
sudo su

# stop NM
/etc/init.d/NetworkManager stop

# start with serial log and tee it in a log file
NM_SERIAL_DEBUG=1 NetworkManager --no-daemon 2>&1 | tee /tmp/nm-serial.txt		 $ udevadm info --query=all --path=/sys/class/tty/... --attribute-walk
Line 60: Line 100:
... reproduce and attach the nm-serial.txt

== Debugging Crashes ==

To install debug symbols, add the following line to your {{{/etc/apt/sources.list}}}
Line 67: Line 101:
deb http://ddebs.ubuntu.com/~ubuntu-archive/ddebs/ hardy main universe $ lsusb
Line 70: Line 104:
or == Captive portal ==
Line 72: Line 106:
You can check the status from the cli using:
Line 73: Line 108:
deb http://ddebs.ubuntu.com/~ubuntu-archive/ddebs/ intrepid main universe $ nmcli networking connectivity check
Line 76: Line 111:
Since 1.38, you can set Environment=NM_LOG_CONCHECK=1 in NetworkManager.service and restart the service to get additional debug logging about connectivity checking.
Line 77: Line 113:
Then install the appropriate dbgsym packages: = A Testcase =
Line 79: Line 115:
A good testcase is a step by step instruction to reproduce your bug starting with driver unloaded and NetworkManager stopped.

First, stop NetworkManager and unload your driver:
Line 80: Line 119:
sudo apt-get update
sudo apt-get install network-manager-dbgsym libnm-util0-dbgsym libnm-glib0-dbgsym libglib2.0-0-dbgsym		 $ sudo systemctl stop NetworkManager
$ sudo modprobe -r DRIVER
Line 84: Line 123:
Then stop NetworkManager (hardy): Next, load the driver and start NetworkManager:
Line 86: Line 125:
sudo /etc/dbus-1/event.d/25NetworkManager stop $ sudo modprobe DRIVER
$ sudo systemctl start NetworkManager
Line 89: Line 129:
or stop NetworkManager (intrepid):
{{{
sudo /etc/init.d/NetworkManager stop
}}}		 = Netplan =
Line 94: Line 131:
Run NetworkManager in a debugger
{{{
sudo gdb /usr/sbin/NetworkManager
...
(gdb) run --no-daemon
}}}		 A configuration abstraction mechanism has added to NetworkManager as of Ubuntu 23.10, called Netplan. There is a whole [[https://netplan.readthedocs.io/en/stable/|library of netplan documentation]] available. However here is a very basic amount of netplan debugging.
Line 101: Line 133:
Once it crashes get a backtrace
{{{
(gdb) bt
...
(gdb) bt full
...
(gdb) thread apply all bt full
...
}}}		 Netplan uses the files in /etc/netplan/*.yaml to generate the running profiles you find at /run/NetworkManager/system-connections/*.nmconnection. If you suspect a feature defined in your /etc/netplan/*.yaml files is not being used, it is a good idea to check that the content matches up.
Line 111: Line 135:
and attach the backtrace above together with your {{{/var/log/syslog}}} to the bug.

== Driver Logs ==

When a bug appears to be driver related or you are asked by a bug triager to submit a driver enabled
log, you need to enable driver logging right before you start to capture your testcase. How to do that depends
on the driver you use and whether it has been with compiled with debug support.


== Driver Specific Info ==
=== IPW (2100,2200, 3945) ===
==== Logging ====
{{{
# either during module load:
 modprobe ipw{2100,2200,3945} debug=65535

# or when already loaded you can change the debug_level through /sys/bus/.../drivers/
 echo 65535 > /sys/bus/pci/drivers/ipw{2100,2200,3945}/debug_level
}}}

==== Compiling Module Sources ====
For debugging purpose or to verify a fix, a developer might ask you to build your driver module from source. for ipwXXXX you can do that by:
{{{
# install required headers and build tools
sudo apt-get install module-assistant
sudo module assistant update
sudo module assistant prepare

# build the driver
cd /path/to/ipw-XXXX
make IEEE80211_IGNORE_DUPLICATE=y SHELL=/bin/bash

# backup your old ipw driver:
sudo cp /lib/modules/$(uname -r)/kernel/drivers/net/wireless/ipw3945/ipw3945.ko $HOME

# install the new driver
cp ipw3945.ko /lib/modules/$(uname -r)/kernel/drivers/net/wireless/ipw3945/
depmod -a

# kill regulatory daemon
ipw3945d-$(uname -r) --kill

#load new module
modprobe ipw3945
}}}

== Bug Tags ==

These tags allow isolation of bugs into smaller groups, providing an easier and faster way to work on specific issues.

||<rowbgcolor="#FFEBBB"> '''Tag''' || '''Use case''' ||
|| [[https://launchpad.net/ubuntu/+bugs?field.tag=driver-madwifi|`driver-madwifi`]] || Bugs in which the madwifi driver is in use ||
|| [[https://launchpad.net/ubuntu/+bugs?field.tag=driver-ndiswrapper|`driver-ndiswrapper`]] || Bugs in which the ndiswrapper driver is in use ||
|| [[https://launchpad.net/ubuntu/+bugs?field.tag=vpn|`vpn`]] || Bugs related to either openvpn, vpnc or pptp network-manager vpn modules ||
|| [[https://launchpad.net/ubuntu/+bugs?field.tag=encryption-wep|`encryption-wep`]] || Bugs in which WEP encryption is used ||
|| [[https://launchpad.net/ubuntu/+bugs?field.tag=encryption-wpa|`encryption-wpa`]] || Bugs in which WPA encryption is used ||
|| [[https://launchpad.net/ubuntu/+bugs?field.tag=encryption-wpa2|`encryption-wpa2`]] || Bugs in which WPA2 encryption is used ||

The previously described tags are specific to the [[NetworkManager]] application, if you need more general tags please visit [[Bugs/Tags]] page.


== Testing a patch ==

Sometimes a developer might ask you to test a quick patch he came up with. Below an example how to do that for network-manager. If your bug is for network-manager-applet or some other package, just replace the package name

{{{
# get build dependencies
sudo apt-get install build-essential fakeroot devtools
sudo apt-get build-dep network-manager

# get sources
sudo apt-get source network-manager

# cd into the source directory
cd network-manager-*/

# apply the patch (note that -p1 could also be -p0 if the patch was created without an extra prefix in the diff path)
patch -p1 < /tmp/yourdownloadedpatch.diff

# build binaries only without signing
debuild -b -nc

# packages are produced in parent directory
cd ../

# install all nm packages
sudo dpkg -i network-manager*.deb libnm-*.deb
}}}


----
CategoryBugSquad		 If you find a netplan bug, please report it here: https://bugs.launchpad.net/netplan/+filebug

Available languages: Italiano,

Debugging Central

This page is part of the debugging series — pages with debugging details for a variety of Ubuntu packages.

Bug Summary

If a network-manager bug report is about not being able to connect the title or summary should be in the format:

"[CHIPSET] cannot connect to (ENCRYPT_METHOD)"

where the CHIPSET is the wireless driver used and ENCRYPT_METHOD is the encryption method used by your wireless network.

Understanding your bug and getting more information

Getting debug logs

You can then follow developers' intructions on a bug report for the exact command line to use; or run it directly as such.

Getting NetworkManager debug logs

By default, the NetworkManager log level is set to info. You can use nmcli to modify the logging level: 

$ sudo nmcli general logging level DEBUG domains ALL

You do not need to restart NetworkManager to begin seeing debug messages logged to journalctl. You can watch the NetworkManager logs: 

$ sudo journalctl -f -u NetworkManager

Getting ModemManager debug logs

Manually run with debug enabled: 

$ sudo /usr/sbin/ModemManager --debug
$ sudo /usr/sbin/NetworkManager --debug --log-level=DEBUG

See also DebuggingModemmanager.

You do not need to restart ModemManager to begin seeing debug messages logged to journalctl. You can watch the ModemManager logs: 

$ sudo journalctl -f -u ModemManager

Getting wpasupplicant debug logs

Change the log level: 

$ sudo wpa_cli log_level debug

You do not need to restart wpa_supplicant to begin seeing debug messages logged to journalctl. You can watch the wpa_supplicant logs: 

$ sudo journalctl -f -u wpa_supplicant

Getting a capture of syslog

Mixing and mashing the above is perfectly acceptable as well if you want to see how NetworkManager and other parts of the stack interact together.

In order to understand whats going on and track down issues, its good to have a full log. To do so, capture the complete test case and submit the whole file (don't cut out what you think is important). Please add markers in the log file so the bug triager can easily see what actions the user takes at what point of time (this isn't essential, but helps a lot).

To capture the syslog, do: 

$ tail -n0 -f /var/log/syslog > /tmp/syslog

and to stop capturing do Ctrl-C (you will have to type your other commands in an other window or tab)

Adding markers is just like adding new lines with an editor that show the triager what happened at what point of time. You can also do this on the fly as you test with the command logger "[ clicked on wireless network 'ubuntu']" .

Example marker: 

Sep  6 08:12:30 ...

[ clicked on wireless network 'ubuntu']

Sep  6 08:12:31 ...
...

Handling 3G / modem issues

Here are a few extra things that are very helpful to add in case of issues with 3G.

The output of udevadm for tty devices, and output of lsusb: 

$ udevadm info --query=all --path=/sys/class/tty/... --attribute-walk

$ lsusb

Captive portal

You can check the status from the cli using: 

$ nmcli networking connectivity check

Since 1.38, you can set Environment=NM_LOG_CONCHECK=1 in NetworkManager.service and restart the service to get additional debug logging about connectivity checking.

A Testcase

A good testcase is a step by step instruction to reproduce your bug starting with driver unloaded and NetworkManager stopped.

First, stop NetworkManager and unload your driver: 

$ sudo systemctl stop NetworkManager
$ sudo modprobe -r DRIVER

Next, load the driver and start NetworkManager: 

$ sudo modprobe DRIVER
$ sudo systemctl start NetworkManager

Netplan

A configuration abstraction mechanism has added to NetworkManager as of Ubuntu 23.10, called Netplan. There is a whole library of netplan documentation available. However here is a very basic amount of netplan debugging.

Netplan uses the files in /etc/netplan/*.yaml to generate the running profiles you find at /run/NetworkManager/system-connections/*.nmconnection. If you suspect a feature defined in your /etc/netplan/*.yaml files is not being used, it is a good idea to check that the content matches up.

If you find a netplan bug, please report it here: https://bugs.launchpad.net/netplan/+filebug

DebuggingNetworkManager (last edited 2023-06-27 20:21:45 by hellsworth)