Netapplet Patchwork
I think I've finally done it -- achieved my ultimate goal of combining the awesome powers of the Debian /etc/network/interfaces file with guessnet, wpa_supplicant, ifplugd and now also with netapplet!
I've been looking for a way to just point-and-click to select a different access point, both at home and at work. To that end I have a pretty advanced interfaces file that automatically detects where I am, what I am connected with (cable/wireless) and then, like magic, sets it all up.
Several times now I have tried, really hard, to get used to and live my life with Network Manager, but it's just plain impossible. It still doesn't integrate well with Debian ifupdown et consortes and until now I've been using ifup to select different wireless mappings:
$ sudo ifdown eth2; sudo ifup eth2=WLAN Password: *********** [Use crappy work AP to access VPN tunnel] $ sudo ifdown eth2; sudo ifup eth2=NETLET Password: *********** [Use family WRT54GL access point]
For the last couple of days I've been looking into getting the old (obsoleted?) Netapplet from Novell. Since I'm a Ubuntu user I'm using the Debian patched-up version by Matthew Garrett (thanks!). I remember using it a couple of years back, at that time I think it worked but now it didn't -- not well at least. I found several bugs and quirks that I have now fixed and published in my own "repository".
I have published everything as a Bazaar branch, using one changeset per patch (small patches), at http://vmlinux.org/jocke/bzr/netapplet-1.0.8, which can be viewed here using bzrweb.
Thursday, 12 July 2007 at 11:37 | /debian | permanent link to this entry
VMWare Kernel Modules for Your New Kernel
My recent post on building Debian kernels misses a subtle but useful point. Namely that of building Debian kernel modules alongside your new kernel. I wanted to run a new kernel with the Ubuntu vmware-player-kernel-source package. I was fumbling around wanting to use module-assistant to do this for me when I stumbled upon on the solution, presented so eloquently by my friend Albert Veli. This gives us a small update to the previous post:
$ wget ftp://ftp.sunet.se/pub/Linux/kernels/v2.6/patch-2.6.20.4.bz2 $ cd linux-2.6.20/ $ bzcat ../patch-2.6.20.4.bz2 | patch -p1 $ cd ../ $ mv linux-2.6.20 linux-2.6.20.4 $ cd linux-2.6.20.4 $ make oldconfig $ fakeroot make-kpkg clean $ fakeroot make-kpkg --initrd kernel_image $ sudo dpkg -i ../linux-image-2.6.20.4_2.6.20.4-7.troglobit_i386.debNext up is installing and building the vmware-player-kernel-source:
$ sudo apt-get install vmware-player-kernel-source $ cd /usr/src $ sudo tar xvfj vmware-player-kernel-source.tar.bz2 $ cd - $ cd linux-2.6.20.4 $ fakeroot make-kpkg modules_clean $ fakeroot make-kpkg modules_image $ sudo dpkg -i ../vmware-player-kernel-modules-2.6.20.4_2.6.20.4-7.troglobit_i386.debYou may, of course, need to tweak the file /etc/kernel-pkg.conf, but there are man pages for that.
Sunday, 25 March 2007 at 23:59 | /debian | permanent link to this entry
Building Debian/Ubuntu Kernels
I have been over this topic so many times now, strangely enough I've managed to make things more complicated than they need to be. It's really this simple:
$ wget ftp://ftp.sunet.se/pub/Linux/kernels/v2.6/linux-2.6.19.2.tar.bz2 $ tar xfj linux-2.6.19.2.tar.bz2 $ cd linux-2.6.19.2/ $ zcat /proc/config.gz .config $ make menuconfig [Tweak to your hearts desire] $ fakeroot make-kpkg --initrd kernel_image $ dpkg -i ../linux-image-2.6.19.2_2.6.19.2-10.00.Custom_i386.deb [DONE!]You may, of course, need to tweak the file /etc/kernel-pkg.conf, but there are man pages for that.
Saturday, 03 February 2007 at 11:00 | /debian | permanent link to this entry
make-kpkg and dirty modules
Dammit, tonight I spent too many hours chasing down a "feature" in the Debian kernel build process or the Linux-2.6 kernel. I haven't yet deciced whom to blame. ;-)
Here goes: when you build the latest Linux 2.6 kernel, checked out from the git repository, with make-kpkg you should make sure to uncheck the CONFIG_LOCALVERSION_AUTO option in the kernel config before hand. It's under "General setup" --> "Automatically append version information ...". If you don't then your utsrelease.h will contain some annoying extra git version string and your modules directory will look something like this: /lib/modules/2.6.18-dirty. All this due to the LOCALVERSION config, your git checkout and the tiny little fact that make-kpkg modifies (moves away) the two files scripts/packages/{builddeb,Makefile} which leads to the modification of the checkout and the scripts/setlocalversion will tell this to the top Makefile which in turn will create this whole mess.
Take my advice, untick the CONFIG_LOCALVERSION_AUTO option. It's the easiest one to get away with.
Monday, 17 July 2006 at 22:10 | /debian | permanent link to this entry
Quick note
About that /etc/network/interface autoconfig thingy: it's almost done. Works perfect ... at work (connected) and at home (wireless). I need to fine tune the tests, I think, to get the connected stuff to work at home too. The problem seems to be that the test to see if the machine is connected at home is that the MAC it looks for to ID the office network also is available from home, via the VPN. I'll get back on the subject as soon as I've done some more tests.
Monday, 17 July 2006 at 21:10 | /debian | permanent link to this entry
Laptop Network Configuration in Debian/Ubuntu
I have three network cards in my laptop. Two built-in and one PCMCIA card. I'm currently investigating how I can migrate from using the slow and tedious gnome-network & C:o tools to the more integrated Debian/Ubuntu tools ifupdown, guessnet, ifplugd and waproamd instead. As usual Debian has a fine and clever way of handling all this with their /etc/network/interface file. To learn more about this fine management interface I'm reading the well written book The Debian System by Martin F. Krafft. I highly recommend it to others wanting to learn the essentials of their Debian (based) system.
What I wanted to do is quite simple actually: The built-in wired interface, named eth0, should on link-up default to a specific IP address if ARP reveals a certain MAC on the network. If plugged in to an unknown net eth0 should go up with DHCP. If eth0 is not up then the built-in wlan card, eth1, should be tried with two different ESSID's, work and home, in that order. If none of the ESSID's could be found any open wlan and DHCP should be the tried. The last, eth2, the PCMCIA card is only used for the lab net and always have the same IP address if plugged inm completely ignoring link status.
When I've implemented the above I'll post the result here.
Tuesday, 06 June 2006 at 21:10 | /debian | permanent link to this entry