Posts Tagged ‘network-manager-gnome’

The Magic of Lenny Backports

September 28th, 2009 No comments

This afternoon saw me in a really annoying situation. I was in a coffee shop, wearing a beret, and writing poetry, and couldn’t get a ‘net connection. The coffee shop runs an open network access point, but some asshat in a nearby complex was running a secured access point with the same SSID.

For some reason, my version of the network-manager-gnome package (the older one that shipped with Lenny) could not tell the difference, and I could not get a connection. When I attempted to force a connection, it crashed. Repeatedly.

This being my first experience with anything on Linux crashing, I immediately (and rashly) determined that the problem must lie with my (relatively) old network manager. After all, I was running v0.6.6-4 of an application that had since matured to v0.7.7-1! And my companions, who were running the latest version, were connecting no problem! Of course, this also wasn’t the first set of problems that I had encountered with my network manager.

So upon returning to my domicile (I’ve always wanted to use that word in a sentence), I hit the #debian IRC channel and asked about upgrading to the testing repository, where all of the latest and greatest code is awaiting release as Squeeze, the next version of Debian. Having heard that the code was frozen in July, and that the release was slated for early spring, I figured that by this point, the code there would be fairly mature, and easy enough to use. To the contrary, the members of the channel weren’t comfortable giving me advice on how to upgrade, since in their words, I shouldn’t be considering upgrading to testing unless I understood how to do as much.

With this warning, I was then given instructions on how to update (which didn’t make me feel any better – the last step in the instructions was “be ready for problems”), along with the suggestion that I check out first.

Essentially, this site is an alternate repository dedicated to backporting the latest and greatest code from testing to the last stable version of Debian. This means that, with a simple modification to my etc/apt/sources.list file, I could selectively upgrade the packages on my machine to newer versions.

In fact, I had actually already added this repository to my sources.list file, back when I was working on getting Flash 10 installed. At the time, I just didn’t know enough to understand what it was, or what it’s implications were.

So now, running the newest version of network-manager-gnome, a somewhat more recent version of gnome-do, and clinging to the promise that I can upgrade anything else that seems to have gotten better since the time of the dinosaurs when Lenny was released; my urge to upgrade has subsided, and my commitment to wait out the proper release has been restored.

Wireless Network Manager Woes

September 16th, 2009 No comments

Debian Lenny ships with the Network Manager package, version 0.6.6-4, which for all intents and purposes is a well written and very useful network management application. But of course, I wanted something more. At home, I have my music library (hosted on a Windows Vista machine) shared to the local network, and wanted to mount that drive using Samba so that I could share my music library between my two machines while on my home network.

On a Windows machine, one can just point an application to files on a networked drive, while Windows handles all of the dirty details related to allowing that application use those files as if they were on the local machine. On Linux, the application in question seems to have to be aware of how to handle a Windows share (usually via the Samba package), and handle that drive sharing on it’s own, unless the network drive has been mounted first. Further, when mounting a network share in Linux, one can choose any folder on their hard drive to put its contents into, ensuring that it always appears in the same location, and is easy to find.

Unfortunately, as far as I can divine, a networked drive can only be mounted by the root user, which seriously reduces the number of applications that can perform that mounting action. In my quest to get my home music share working, I looked into plenty of different methods for automatically mounting network drives, including startup scripts, modifying the fstab file, and manually connecting from a root terminal. None worked very well.

Eventually, I stumbled across a web post advertising the pros of the WICD network manager, which as I understand, will be used as an alternative to the network manager package by Debian Squeeze, and can currently be pulled into Lenny by adding the Debian-Lenny Backports repository to your sources list. I installed it, replacing the default network-manager-gnome package.

My first impression of WICD was extremely positive. Not only did it connect to my home network immediately, it also allowed me to define default networks to connect to (something that is conspiciously absent from the NetworkManager interface), and to set scripts that are run when my client connects to or disconnects from any of the networks in the list. This allowed me to write a simple one line script that mounted my network share on connection to my home wireless network. It worked every time, and mysteriously did so without asking me for my Sudo password, even though it used the sudo command internally to get rights to perform the mount.

Odd security peculiarities aside, I was happy with what I had accomplished – now I could tell my laptop to automatically connect to my home wireless network, and to mount my music share as soon as it did so! Then I went to school. Shit.

The wireless network at my University uses EAP-TTLS with PAP inner-authentication as a security protocol, something that WICD apparently had no idea how to handle. This protocol is extremely secure, as the host identifies itself to the client with a certificate that the client uses to tunnel into the host, allowing connection to take place without any user information being passed in the clear. At least that’s how it’s supposed to work, except that our school doesn’t have a certificate or certificate authority, so… Whatever.

In any case, WICD does not include a template for this type of network (which is fair I suppose, since Windows requires an add-on to access it as well), but for the life of me, I couldn’t figure out what to do to fix the problem. I trolled the internet from a wired machine and tried editing the WICD encryption templates, while Tyler (on Fedora) and Phil (on OpenSuse) connected on first try.

Eventually, after an hour or so of fruitless trial and error, I gave up, came home, and reinstalled the NetworkManager application, because that’s what Tyler and Phil were using on their systems, and it seemed to work fine. Sure enough, the next day I connected after just a minor tweaking of the network properties in the NetworkManager dialog.

Unfortunately, while I can now connect to my home and school networks, I once again have lost the ability to automatically connect to networks, and to execute scripts on connection, meaning that I’m back to square one with the mounted networked music share – for now, I just do the mounting manually from a root terminal. Balls.