Tokamak IV, Network Management

This morning I’ve boarded the train of my second leg of the February round trip. I’ve spent a couple of days at the KDAB office, for a meeting of the team I’m part of. As usual, it was nice to meet with my colleagues. I was positively surprised by a great new feature in our Berlin office, a ping-pong table. I hadn’t played ping-pong in quite a while, so it took me some time getting used to lightweight and spinning balls, but I got up to speed quickly again and was even able to slash some of my colleagues a couple of times (you know who you are, no reason to embarrass you en plein public). Admittedly, I didn’t win every game, but let’s stick to the bright side of life.

Next stop on this trip is Nürnberg, in Southern Germany (it’s actually the city where the 3rd Reich’s race separation laws have been signed (the notorious "Nürnberger Gesetze"), but also the place where the Nazi trials after world war II were held as a display to the world that even those who do unimaginable harm to humanity were put to trial to have justice rule. Surely an interesting place from that point of view. After Tokamak, I’ll be meeting K in Düsseldorf next Friday, where we’re staying for the weekend, for a bit of sight-seeing and the Depeche Mode concert that will be held there on Saturday. From Jesper (KPhotoAlbum and KDAB training dude, and ), I’ve heard that Nitzer Ebb might be one of the support act. I didn’t know them yet (shame on me), so I’ll have to do some cultural catch-up before next week as well. (Fancy words for "listening to electronic music during hacking" ;)).

The reason why we’re in Nürnberg has nothing to do with history or music though. openSUSE has kindly offered us to host and sponsor (together with the KDE e.V.) three developer sprint that are closely related to each other: The 3rd Oxygen Meeting, a small KWin sprint (the first of its kind, to my knowledge) and the 4th installation of Tokamak, the half-yearly meeting of the Plasma team.

From a social point of view, I’m really looking forward to going to Nürnberg and meeting all those cool guys and gals that have become real friends over the years. Rather than going wild on how I love my fellow Plasma hackers, let me explain a bit what my personal plans for this sprint are. Those revolve around two topics, Network Management and Silk. In this blog entry, I’ll share some details about the network management infrastructure and UI we’ve been working on for almost two years now, and I’ll save Silk for another blog entry. You could also consider dropping by during the Open Day we’ll hold during the sprint, as I’ll be sharing some information about that in a presentation about Silk. Anyway …

Network Management

As you know, the network management tools in Plasma have been in development and "close to being ready" for quite a long time now. With 4.4, most distros ship the knetworkmanager tool, which is basically an icon in the Notification Area (system tray) offering a menu to choose your connection. Also in the works is a Plasma widget to do the same, but with a more attractive user interface. My work mostly concentrates on this applet.


The overall architecture of the network management infrastructure in Plasma is a bit more complex than one might expect at first, but as you understand it, you’ll find out that It All Makes Sense. On the platform side of things of a typical Linux system, there’s the wifi driver stack, which is exposed to low-level tools such as WPA supplicant (and in extension to that networkmanager for example). Depending on the system, this could also be WICD, or Intel’s ConnMan (weird name, as Mike suggested yesterday during dinner). KDE’s network management tools sit on top of those lower-level infrastructure and put a unified user interface on top of that. The user doesn’t care which exact backend is in use, she just wants to get online, hassle-free and reliable. So KDE has a small network management client, which basically brokers information between the UI layer, and the middleware that takes care of the actual connection. This information can be "which wireless networks are available", "the user wants to connect to this network", "a password is needed to connect", and so on. So the information going through this broker is bi-directional. As communication channel, DBus is used. This broker is implemented as a kded module, a small plugin that is managed by a daemon in the KDE desktop (and which makes it possible to do "daemon-like" stuff by just writing a plugin, and reduced the number of processes that need running in the background). This daemon uses a backend for one of the lower-level connection tools, so that it abstracts away the differences between for example WICD and ConnMan. The Plasma Widget, when starting receives information from this DBus service and uses it to pass on user actions to the underlying infrastructure. So the layering is basically kernel – middleware – kded module – UI. Quite complex for something that’s presumably as simply as getting a network connection up, but it allows us to unify the UI for different systems, and hide system details from the user, while allowing her to choose the mechanism that works best, or is the preferred way of connecting for a given system. It allows you to use something else than NetworkManager if that doesn’t work for you for some reason, for example.

knetworkmanager vs. Network Management Plasma Widget

The tool that is currently the most reliable is knetworkmanager. A standalone application that embeds itself in the notification area. It uses the same set of libraries the network management kded module uses. This might at first be a bit confusing, because it sits one step lower in the stack than you’d expect. This is a shortcut actually, and more of an interim solution for us — it did allow us to test the abstraction and to get something working out to our users relatively quickly. Our goal is to get the Network Management Plasma Widget up to snuff. Some distros include the Plasma Widget already, but I’d only advise using it for the adventurous. If you just want something that works, use knetworkmanager for now. If you do want to try the Plasma Widget, there’s a catch though. In order to not get in the way of other clients (see below), we disabled auto-loading of the kded module for now, based on "we’d rather have something broken that isn’t supposed to be fully working anyway, than break the recommended tool". Sounds logical, right? :)

For NetworkManager, the situation is a bit special. There can only be one UI-client managing the NetworkManager daemon running in the background and taking care of the connection details. This means you can only use one out of knetworkmanager, GNOME’s nm-applet and the network management Plasma widget. Now let’s assume you’re adventurous, say a Lara Croft or an Indiana Jones of Free Software, and you want to check out the Network Management Plasmoid. First make sure it’s installed, this depends on your distro, so I won’t go into details here. Some will use KDE compiled from sources (you’ll currently find our stuff in kdereview), in that case you should be able to add the Network Management Widget to your Plasma Workspace using the normal "Add Widgets" mechanism. You’ll find yourself puzzled why it doesn’t work at first, but then you recall why that is, and of course you’re happy that you actually read this article. Then you stop the currently running network management thing (killall nm-applet, for those using the GNOME thing, kquitapp knetworkmanager for those relying on knetworkmanager at the moment). (kquitapp is the nice way of stopping a KDE application, it will make sure to cleanly quit and for example sync changes in the configuration to your disk, so it prevents possible data loss, compared to UNIX’ kill command. But I digress.) Of course it still doesn’t work (scroll up to re-read why!). Right, there’s something missing in between, the kded module, so there’s nothing to broker information between UI and lower-level infrastructure.

qdbus org.kde.kded /kded loadModule networkmanagement

will do that for you, and all of a sudden you’ll see available wireless networks showing up, and things looking less bare-bones and more promising. If you have your network already configured, you’ll see that you’re being connected automatically now (of course knetworkmanager and the Plasma widget share configuration, so they’re interchangeable), but you’ll also notice that some things aren’t working as expected yet, there are glitches in the UI, and some other bits that aren’t perfect yet. Those are the things we’ll be working on during Tokamak IV.

You might also find your setup not working at all. In this case, you’ll want to roll back, which means unloading the kded module the Plasmoid uses and starting your preferred client again. Unloading the DBus module is easy:

qdbus org.kde.kded /kded unloadModule networkmanagement

Then just run "knetworkmanager &" (for example), and you should be good to go again. (But you just lost some Lara/Indiana-karma of course, can’t have your cake and eat it, too.)

Finally, some personal words on Network Management in KDE SC. I feel kind of bad that we weren’t able to nail the whole network management thing in KDE SC yet. I think it’s one of those central components of system integration that should just work. Thanks to the work of Will Stephenson, we’re pretty close. As others have promised to jump in during the last days (Kevin, our Solid guru, Aurelien, Kubuntu-hacker extraordinaire, Shantanu of Plasmate fame and Sandro, who has been working on the cool KDE observatory in Plasma), Given this cool group, I’m pretty confident we’ll make good progress towards our goal. I hope that, by the end of next week, we have a working beta version of the Plasmoid in place, without known major bugs that we can hand out for testing by a wider base of potential users. From there on, it’s fixing bugs we haven’t seen yet, and ironing out smaller kinks. I’ll not be promising anything (I know better now ;)), but hard work is better than promises anyway, so let’s just see how far we get.

Special double-thanks go out to Will Stephenson, who has been awesome on both, the network management front and in hosting the Oxygen, KWin and Plasma bunch in Nürnberg.

Posted in KDE

16 thoughts on “Tokamak IV, Network Management

  1. I am travelling around Europe and staying in various hostels using wifi networks sometimes with wep encryption and sometimes wpa.

    It’s very unfriendly in KDE that it doesn’t detect the encryption type automatically. Therefore, I get a failed connection because the default dialogue asks for a password for wep when the network actually uses wpa. To be sure I test the network in windows vista which is kind enough to show which encryption the network uses. When you choose a network it automatically sets up the connection properties regarding encryption type. I suppose we could say the password dialogue is encryption-type agnostic.

    This seems to me to be a basic feature that so far is badly missed in KDE SC 4.4. Is this on the agenda to be rectified?

    1. Only if people file bugs to help us identify this kind of things.

      In general, yes, we want to do that, if it doesn’t work, it’s a bug.

        1. Make sure you’re using the latest version, Kubuntu for example ships an outdated version (which indeed exposes this bug).

  2. Hi there,

    Where would I be able to find more detailed error information for knetworkmanager? I have a problem where a connection always fails on “Acquiring network address.”

    My specific problem is a wireless card (Intel ipw2200) that displays networks but doesn’t connect to them. Apparently this is an old problem and was fixed in newer drivers, but I still have the problem, and I don’t know where to find the more detailed information to resolve it. The iwconfig-type commands don’t seem to be very useful.


    1. Tools such as dhclient, iwconfig can tell you what’s going on in the lower levels of the stack. If you’re using NetworkManager, you can use nm-tool to find out what NetworkManager thinks is happening. From there on, you can refer to Techbase.

    1. The artwork is only temporary at this point, you’re right that the icon is confusing and semantically simply misleading.

  3. Hi,

    Just for the record, as I’m a french speaker :
    “en plein public”

    Where ‘plein’ means ‘full’ ; but the expression, you seems to got it right, means ‘in front of the whole crowd’.
    ‘Plain’, on the other hand, means something large and plane. If the masculine (?) form is not often used, the feminine (?) one (plaine) is largely used.

    I hope you are still open to improve your languages skills :) (at least the spelling)

  4. Nice post. A while back I wanted to get involved in knetworkmanagement development, but I couldn’t find the big picture and where things are moving.

    1. Yes, one problem we’re having as well. NetworkManager itself is pretty much completely undocumented, the stack we’ve put on top of it is not yet mature (though the code is readable). In doubt, catch wstephenson or me on IRC (#kde-devel on Freenode).

  5. Hi!

    It’s really great to see KDE and Plasma enhancing in even more areas. You guys rock!

    Regarding GSM/GPRS/3G/HSDPA/LTE connections, you could take a look at Betavine Connection Manager, which is an evolution of Vodafone Mobile Connect Card driver for Linux rearchitected around Wader (all of them GPLed). A working mobile broadband manager is a must-have for netbooks.

    BCM-core is a daemon which implements the D-BUS ModemManager API, so BCM and NetworkManager are able to work standalone or side-by-side. BCM-core supports more than 50 GSM/GPRS/3G/HSDPA/LTE devices and is the official Connection Manager for Linux from Vodafone. It’s very easy to integrate a GUI with BCM-core, currently we have three: Wader-UI, BCM-UI and BCM-UI for Moblin (it was created before the MeeGo merge). BCM-core depends on gconf currently, but removing this dependency is in our roadmap.

    You would probably be also interested in ntrack integration with Solid.



    1. This information would be good to have on the list, so you don’t rely on me not forgetting it.

      I basically have no personal interest in the mobile broadband stuff myself at this point, since my personal life pattern would make it insanely expensive (I’d only use mobile broadband while roaming internationally …).

Comments are closed.