NetworkManagement: Difference between revisions

From KDE UserBase Wiki
(bug reporting info)
 
(→‎Where Does It Hurt?: Arch Linux uses whatever the user wants it to use and certainly not wicd by default.)
 
(20 intermediate revisions by 10 users not shown)
Line 1: Line 1:
{{Template:I18n/Language Navigation Bar|NetworkManagement}}
<languages />
<translate>
== Introduction == <!--T:1-->
On several Linux distributions, the '''NetworkManager''' daemon provides user-configurable control of network connections. In KDE, the '''KNetworkManager''' (KDE3 and KDE4) and '''Network Management''' (KDE4) are the main user interfaces to '''NetworkManager'''.


= Introduction =
== Bugs == <!--T:2-->
On several Linux distributions, the NetworkManager daemon provides user-configurable control of network connections. In KDE, the KNetworkManager (KDE3) and Network Management (KDE4) are the main user interfaces to NetworkManager. 
=== Reporting Bugs ===
 
To report a useful bug against '''Network Management''', provide the following items of information:
== Reporting Bugs ==
To report a useful bug against Network Management, provide the following items of information:
* Your distro version
* Your distro version
* The version of the Network Management applet (NetworkManager-kde4.rpm on openSUSE, plasma-applet-networkmanager on kubuntu)
* Is '''NetworkManager''' in use?  On some distributions it is optional, as it is out of place on a static, server-like system.  Stop now if it is not.
* The version of the NetworkManager package
* The version of the ''Network Management'' applet (NetworkManager-kde4.rpm on '''openSUSE''', plasma-widget-network-manager in '''Kubuntu 9.04''', plasma-widget-networkmanagment in '''Kubuntu 9.10''', kde-plasma-networkmanagement on '''fedora''')
* Your network hardware (use lshal to find this out)
* The version of the '''NetworkManager''' package
* A system log from NetworkManager during the connection attempt
* The version of the '''ModemManager''' package
** for openSUSE: /var/log/NetworkManager
* Your computer's hardware if not a vanilla x86 compatible. PPC user? I want to know.
** for kubuntu: /var/log/syslog
* Your network hardware (use ''lshal'' to find this out)
** for fedora: /var/log/messages
* A system log from '''NetworkManager''' during the connection attempt
** for '''openSUSE''': /var/log/NetworkManager
** for '''kubuntu''': /var/log/syslog
** for '''fedora''': /var/log/messages


<!--T:3-->
* For wireless networks:
* For wireless networks:
** Is it using a hidden SSID?
** Is it using a hidden SSID?
Line 23: Line 28:
** Auth mechanisms (TLS/TTLS/PEAP/...)
** Auth mechanisms (TLS/TTLS/PEAP/...)


<!--T:4-->
* For mobile broadband:
* For mobile broadband:
** hardware
** hardware
Line 29: Line 35:
** network type (GSM/CDMA/UMTS)
** network type (GSM/CDMA/UMTS)
** apn used, if any.
** apn used, if any.
** '''ModemManager''' logs ("killall NetworkManager", "killall modem-manager", start "modem-manager --debug", "NetworkManager --no-debug") may be helpful in debuggin whether '''NetworkManager''' detects your hardware.
<!--T:5-->
And very importantly: Are you able to connect with another client?
For example, '''nm-applet''' under GNOME or '''cnetworkmanager''' on the console.
If so, please try to attach comparative troubleshooting information as described at the end of this article.
=== Bug handling === <!--T:6-->
<!--T:7-->
Network Management on most Linux desktops sits on top of a large and fragile stack of components.  This is necessary to deal with the vast number of different configurations.  When a connection fails, it can be for any one of a number of reasons throughout this stack, but the symptoms will usually be something like "Connection got to 28% and then failed".  Bugs reported at bugs.kde.org will be triaged to try and find out at what layer the failure occurred, so that it can be fixed by those responsible.
== The Stack == <!--T:8-->
=== The Hardware === <!--T:9-->
<!--T:10-->
Wireless hardware has a surprising number of bugs.  These are dealt with at the next layer, if you are lucky.
=== The Kernel === <!--T:11-->
<!--T:12-->
This is where the actual driver that controls the hardware is located.  There are many interesting bugs here too.  Since the introduction of a standard wireless MAC layer in the Linux kernel, this situation is improving.  Some hardware doesn't have a Linux driver, so people control it using the '''ndiswrapper''' tool, which loads '''Windows''' drivers and their bugs. You can see its output in the system log, and talk to the drivers using the '''iwtools''' set of commands.
=== WPA Supplicant === <!--T:13-->
<!--T:14-->
'''wpa_supplicant''' is a low level tool for talking to the driver, providing authentication and encryption settings.  It is open source and generally of high quality.  Before the advent of '''NetworkManager''', users had to configure it manually with control files in /etc.  This has been known to get people out of a tight spot occasionally.  It usually logs to /var/log/wpa_supplicant.log.  Nowadays it is mostly controlled remotely by....
=== NetworkManager === <!--T:15-->
<!--T:16-->
'''NetworkManager''' is the system daemon at the centre of the networking subsystem on most end user Linux installations.  It has root privileges, needed to control the lower layers, and exposes some controls up to clients running in the user session via '''DBUS'''.  It writes a log in /var/log.  ''NM'' also controls ''DHCP'' clients as needed and rewrites /etc/resolv.conf with the ''DNS servers'' it has configured. '''NetworkManager''' also provides a '''SystemSettings''' service, which is responsible for reading your distribution's network configuration files (system wide) and feeding them into '''NetworkManager'''.
=== User Clients === <!--T:17-->
<!--T:18-->
'''KNetworkManager''' applet for KDE 4, '''Network Management Plasmoid''' under KDE 4, '''KNetworkManager''' under KDE 3, '''nm-applet''' under GNOME, and '''cnetworkmanager''' is your last life.  These are responsible for
* giving feedback on the networking status of this system,
* communicating the user's actions to '''NetworkManager''',
* and for storing and communicating the user's network connection details (policy) to NM.
While they are the most visible part of the system, they are also the least important to making a successful connection. 
Since they share a standard interface to '''NetworkManager''', they can be exchanged easily.
== When Things Go Wrong == <!--T:19-->
=== Where Does It Hurt? === <!--T:20-->
<!--T:21-->
Simple.  Start at the top of the stack and work down.  When you find something that works, you found the site of the problem.  When you run out of things you can change, hand over to an expert (probably the responsible team at your Linux distribution).
<!--T:22-->
# Are you actually using '''NetworkManager''' on your system?  '''Mandriva''' doesn't use it.  '''Moblin''' uses '''Connman'''. 
# Try a different '''NetworkManager''' client.  If that helps, continue in the next section to try and further localize the problem in '''Network Management'''.  Then bugs.kde.org, product "Network Management" is the place to go.
# Try to configure a connection using your distro's system configuration tools, so '''SystemSettings''' picks it up.  It's unlikely but worth a go.
# Try a manually configured connection via '''wpa_supplicant'''.  The documentation is rather sparse but there are example configurations include in the package.  Here is the [http://hostap.epitest.fi/wpa_supplicant/ list of supported hardware].  If wpa_supplicant on its own works, '''NetworkManager''' is at fault.  Talk to your distro or report it at bugs.freedesktop.org.
# If that didn't work, reconfigure a wireless router to use a different (weaker) encryption type or none at all.  If this works, the problem is either in '''wpa_supplicant''' or the driver.  Either way, take it to your distro.
=== It's All KDE's Fault! === <!--T:23-->
If you are reading this, you will have been able to make a connection using a different '''NetworkManager''' client. 
<!--T:24-->
First, make sure that you are not running another client as well as '''Network Management'''.  This will lead to unpredictable results.  If you were, remove and restart '''Network Management'''.  You can run it externally to '''Plasma''' as  {{Input|1=plasmoidviewer networkmanagement}} if you want.
<!--T:25-->
You should now try to figure out how the connection provided by '''Network Management''' differs from that provided by the other client. If you build '''Network Management''' from source you can use the tool 'qdbusfornm', which is a version of qdbus extended to handle NM's data types.
<!--T:26-->
If you do not build from source, just replace {{Input|1=./qdbusfornm --system}}by {{Input|1=qdbus --system --literal}} in the command shown below. It is a bit harder to read but should give you the same output.
<!--T:27-->
If you use {{Input|1=qdbus --system --literal}}please take the time to format the output so there is one key per line, similar to the qdbusfornm output below.  This is easy and just takes time, so it is better for you to do this than a developer.
<!--T:28-->
The value 0 below identifies the connection.  Change it if you have more than one until you find the relevant connection.
<!--T:29-->
{{Input|1=./qdbusfornm --system org.freedesktop.NetworkManagerUserSettings /org/freedesktop/NetworkManagerSettings/0
org.freedesktop.NetworkManagerSettings.Connection.GetSettings}}
<!--T:30-->
returns here
{{Output|1=<nowiki>a{sa{sv}}(==802-11-wireless==
band: bg
mode: infrastructure
security: 802-11-wireless-security
ssid: opensuse-guest
==802-11-wireless-security==
auth-alg: open
key-mgmt: wpa-psk
wep-tx-keyidx: 0
==connection==
autoconnect: true
id: openSUSE
type: 802-11-wireless
uuid: {951cc7d9-1fa0-4525-9ab7-7199849e1b19}
==ipv4==
dns-search:
method: auto
)</nowiki>}}
Now you should repeat using the other, working client and copy both sets of output, before attaching them securely to a bug report at bugs.kde.org.  With this information we will quickly be able to implement a fix.
==== Crashes ==== <!--T:31-->
<!--T:32-->
If you have a crash ensure you install [http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports debugging symbols] and take a backtrace.  In '''Kubuntu''' you need to add the [https://wiki.kubuntu.org/DebuggingProgramCrash debug repository] and install '''plasma-widget-networkmanagement-dbgsym'''.
<!--T:33-->
[[Category:System]]
</translate>

Latest revision as of 09:13, 16 September 2011

Other languages:

Introduction

On several Linux distributions, the NetworkManager daemon provides user-configurable control of network connections. In KDE, the KNetworkManager (KDE3 and KDE4) and Network Management (KDE4) are the main user interfaces to NetworkManager.

Bugs

Reporting Bugs

To report a useful bug against Network Management, provide the following items of information:

  • Your distro version
  • Is NetworkManager in use? On some distributions it is optional, as it is out of place on a static, server-like system. Stop now if it is not.
  • The version of the Network Management applet (NetworkManager-kde4.rpm on openSUSE, plasma-widget-network-manager in Kubuntu 9.04, plasma-widget-networkmanagment in Kubuntu 9.10, kde-plasma-networkmanagement on fedora)
  • The version of the NetworkManager package
  • The version of the ModemManager package
  • Your computer's hardware if not a vanilla x86 compatible. PPC user? I want to know.
  • Your network hardware (use lshal to find this out)
  • A system log from NetworkManager during the connection attempt
    • for openSUSE: /var/log/NetworkManager
    • for kubuntu: /var/log/syslog
    • for fedora: /var/log/messages
  • For wireless networks:
    • Is it using a hidden SSID?
    • Wireless security type: WEP/WPA-PSK/WPA-EAP?
    • Key length
    • Key type (passphrase or hex for WEP)
    • Ciphers (TKIP/AES)
    • Auth mechanisms (TLS/TTLS/PEAP/...)
  • For mobile broadband:
    • hardware
    • driver in use (see dmesg when you connect the hardware)
    • network in use
    • network type (GSM/CDMA/UMTS)
    • apn used, if any.
    • ModemManager logs ("killall NetworkManager", "killall modem-manager", start "modem-manager --debug", "NetworkManager --no-debug") may be helpful in debuggin whether NetworkManager detects your hardware.

And very importantly: Are you able to connect with another client? For example, nm-applet under GNOME or cnetworkmanager on the console. If so, please try to attach comparative troubleshooting information as described at the end of this article.

Bug handling

Network Management on most Linux desktops sits on top of a large and fragile stack of components. This is necessary to deal with the vast number of different configurations. When a connection fails, it can be for any one of a number of reasons throughout this stack, but the symptoms will usually be something like "Connection got to 28% and then failed". Bugs reported at bugs.kde.org will be triaged to try and find out at what layer the failure occurred, so that it can be fixed by those responsible.

The Stack

The Hardware

Wireless hardware has a surprising number of bugs. These are dealt with at the next layer, if you are lucky.

The Kernel

This is where the actual driver that controls the hardware is located. There are many interesting bugs here too. Since the introduction of a standard wireless MAC layer in the Linux kernel, this situation is improving. Some hardware doesn't have a Linux driver, so people control it using the ndiswrapper tool, which loads Windows drivers and their bugs. You can see its output in the system log, and talk to the drivers using the iwtools set of commands.

WPA Supplicant

wpa_supplicant is a low level tool for talking to the driver, providing authentication and encryption settings. It is open source and generally of high quality. Before the advent of NetworkManager, users had to configure it manually with control files in /etc. This has been known to get people out of a tight spot occasionally. It usually logs to /var/log/wpa_supplicant.log. Nowadays it is mostly controlled remotely by....

NetworkManager

NetworkManager is the system daemon at the centre of the networking subsystem on most end user Linux installations. It has root privileges, needed to control the lower layers, and exposes some controls up to clients running in the user session via DBUS. It writes a log in /var/log. NM also controls DHCP clients as needed and rewrites /etc/resolv.conf with the DNS servers it has configured. NetworkManager also provides a SystemSettings service, which is responsible for reading your distribution's network configuration files (system wide) and feeding them into NetworkManager.

User Clients

KNetworkManager applet for KDE 4, Network Management Plasmoid under KDE 4, KNetworkManager under KDE 3, nm-applet under GNOME, and cnetworkmanager is your last life. These are responsible for

  • giving feedback on the networking status of this system,
  • communicating the user's actions to NetworkManager,
  • and for storing and communicating the user's network connection details (policy) to NM.

While they are the most visible part of the system, they are also the least important to making a successful connection. Since they share a standard interface to NetworkManager, they can be exchanged easily.

When Things Go Wrong

Where Does It Hurt?

Simple. Start at the top of the stack and work down. When you find something that works, you found the site of the problem. When you run out of things you can change, hand over to an expert (probably the responsible team at your Linux distribution).

  1. Are you actually using NetworkManager on your system? Mandriva doesn't use it. Moblin uses Connman.
  2. Try a different NetworkManager client. If that helps, continue in the next section to try and further localize the problem in Network Management. Then bugs.kde.org, product "Network Management" is the place to go.
  3. Try to configure a connection using your distro's system configuration tools, so SystemSettings picks it up. It's unlikely but worth a go.
  4. Try a manually configured connection via wpa_supplicant. The documentation is rather sparse but there are example configurations include in the package. Here is the list of supported hardware. If wpa_supplicant on its own works, NetworkManager is at fault. Talk to your distro or report it at bugs.freedesktop.org.
  5. If that didn't work, reconfigure a wireless router to use a different (weaker) encryption type or none at all. If this works, the problem is either in wpa_supplicant or the driver. Either way, take it to your distro.

It's All KDE's Fault!

If you are reading this, you will have been able to make a connection using a different NetworkManager client.

First, make sure that you are not running another client as well as Network Management. This will lead to unpredictable results. If you were, remove and restart Network Management. You can run it externally to Plasma as

plasmoidviewer networkmanagement

if you want.

You should now try to figure out how the connection provided by Network Management differs from that provided by the other client. If you build Network Management from source you can use the tool 'qdbusfornm', which is a version of qdbus extended to handle NM's data types.

If you do not build from source, just replace

./qdbusfornm --system

by

qdbus --system --literal

in the command shown below. It is a bit harder to read but should give you the same output. If you use

qdbus --system --literal

please take the time to format the output so there is one key per line, similar to the qdbusfornm output below. This is easy and just takes time, so it is better for you to do this than a developer.

The value 0 below identifies the connection. Change it if you have more than one until you find the relevant connection.

./qdbusfornm --system org.freedesktop.NetworkManagerUserSettings /org/freedesktop/NetworkManagerSettings/0
org.freedesktop.NetworkManagerSettings.Connection.GetSettings

returns here

a{sa{sv}}(==802-11-wireless==
 band: bg
 mode: infrastructure
 security: 802-11-wireless-security
 ssid: opensuse-guest
 ==802-11-wireless-security==
 auth-alg: open
 key-mgmt: wpa-psk
 wep-tx-keyidx: 0
 ==connection==
 autoconnect: true
 id: openSUSE
 type: 802-11-wireless
 uuid: {951cc7d9-1fa0-4525-9ab7-7199849e1b19}
 ==ipv4==
 dns-search:
 method: auto
 )

Now you should repeat using the other, working client and copy both sets of output, before attaching them securely to a bug report at bugs.kde.org. With this information we will quickly be able to implement a fix.

Crashes

If you have a crash ensure you install debugging symbols and take a backtrace. In Kubuntu you need to add the debug repository and install plasma-widget-networkmanagement-dbgsym.