Non-interactive router reboot HOWTO

7 04 2009

Hi everyone!

I’ve recently been having trouble with a router getting all bunged up due to the high levels of data passing through it. Invariably, I come in in the morning and we’ve lost access to the Internet from some of our stations until I’ve rebooted it. While I’m in the process of building a routing box for the network, I wanted to know if I could automagically have the router reboot itself well before anyone would be wanting access.

As with almost EVERYTHING Linux oriented, the answer is OF COURSE I CAN!

There’s a nifty little utility within Linux called expect. It comes as standard with Slackware, so no installation needed for me. It allows pre-programmed non-interactive access to normally interactive shells. The script I’ve written looks like this:

#!/usr/bin/expect -f
set address [lindex $argv 0]
set username [lindex $argv 1]
set password [lindex $argv 2]
set routercmd [lindex $argv 3]
spawn telnet $address
expect "Login:"
send -- "$username\r"
expect "Password:"
send -- "$password\r"
# This command gets us out of the default menu and into a shell
expect "> "
send -- "sh\r"
expect "# "
send -- "$routercmd\r"
send -- "^D"
send -- "^D"

As you can see, expect is used as the script handler with the -f flag, which would usually point to a script file to be run.

The script really is incredibly simple…

It takes 4 arguments in this order:
address – The router’s IP,
username – The router’s admin username
password – The router’s admin password
routercmd – The command which you wish to run

In my case, I’ve set up a cron job to run daily at 4.40am (the default for cron.daily) which runs the command /usr/local/bin/routercommand.exp **username** **password** reboot. I am yet to see whether 4.40am is suitable, but it’s a step in the right direction!

Anyway, I hope this has been of interest or maybe even use!


UPDATE – 09/04/09

This has completely fixed our problems with the router. We have seen flawless behaviour since. Whoo! Now if I could only get Smoothwall doing PPPoA with the router in bridge mode! Any ideas would be very helpful!


UPDATE – 24/04/09

It seems that all of these modem/routers which claim to fully support bridge mode are at best exaggerating. The best results it is apparent that you can expect is intermittency, which is TOTALLY USELESS in a production environment. The way forward is using a true PPPoA to PPPoE bridge modem. I’m using a Draytek Vigor 110, because by all accounts it ACTUALLY WORKS (shock, horror!).

Anyway… Just thought I’d feed you all that useful little nugget of knowledge. Hopefully I’ve saved even one person from losing sleep over it.


Optimising Slackware boot time (part 1).

21 02 2009

Hi all! This is easily going to be my most in depth post so far, so buckle up…


As you may know, Slackware is widely regarded as one of the most lightning-fast Linux distros. Nevertheless, this isn’t enough for some of us pedantic OS hackers.

My aim was to boot the test system with all required services and a media centre system on top in under 1 minute. On previous Slackware installs this had taken up to 2.5 minutes from power-on to operational (Slack 10.1 and ReiserFS on a 160Gb IDE HDD). This is absolutely ridiculous. My aim has been to get it down to well under 1 minute, and this meant getting the initial bootup to around 20 seconds, as the software takes around 20 seconds to initialise, leaving up to 20 seconds for POST on a VIA EPIA EN15000G, which should be easily enough.

While this may sound difficult, it’s really not that bad. The Slackware boot process (in a much simplified form) works in the following sequence:

1 – Kernel loaded
2 – Initrd/initramfs loaded
3 – rc.S executed (runlevel 1)
4 – rc.M executed (runlevel 2/3)
5 – X started (runlevel 4)

Time to make a plan

I knew that ReiserFS was out of the question for data partitions, as recovery of the journal takes an absurd amount of time. I eventually decided on Ext3 for system partitions and JFS for the media partition. The change from ReiserFS on the system partitions came given the uncertainty of it’s future.

I chose Ext3 over Ext4 because I feel that Ext4 is still a little bit too recent to be trusting an entire system with, however give it a year or two and there will be no question. If you’re interested in looking up Ext4, there’s an in depth review of it here. It looks worlds better than even Ext3.

I chose JFS for the data partition as it’s very fast and deals with large files really well, making it ideal for digital media. Also it’s journal recovery speeds are really fast, allowing me to keep boot time to a minimum.

Ok… On with the hack!

Right… Now we’ve got a plan we can start the implementation.

The first stage is to install Slackware from the DVD. I’m using 12.2, as it’s the latest and greatest, and will STILL more than happily run on a 1.5GHz machine.

If you’ve ever installed Slackware before, you’ll know that you’ve got to do all of your partitioning beforehand. I tend to use CFDisk after booting from the DVD, but if that all looks a bit daunting, a nice easy way to partition is to download the GParted LiveCD, which lets you do it all through a graphical interface.

My partitions run as follows:

hda1 – 500Mb – /boot
hda2 – the rest – extended partition to contain others
hda5 – 1Gb – SWAP
hda6 – 500Mb – /home
hda7 – 2Gb – /
hda8 – 5Gb – /usr
hda9 – 1Gb – /var
hda10 – Whatever’s left – /home/media

I’ll post the next section later today. Don’t want to put it all into one post, as it’ll be hugely too long. Don’t want to cause a case of tl;dr.


CUPS + Slackware = Headache.

18 02 2009

Hi! Not a very descriptive title I know, but one that describes exactly how I’ve been feeling for the last couple of days. I’ve been fighting with CUPS on one of my servers. I’ve seen a lot of forum posts all over the web wondering why they can’t seem to add local printers connected via USB/parallel… I finally understand why. Apparently entering your root password into the CUPS web interface doesn’t give you root permissions, it just allows you to access the admin features of the GUI. Here was my misunderstanding… The 3 second fix for this:

chmod a+rw /dev/usb/lp*

Wasn’t that easy? If you now go to the web interface at http://localhost:631 (assuming you have activated it), when you add a printer, it’ll pick it up straight away. Now just follow the prompts, and if necessary choose a PPD and you’re away!

The problem I immediately see is that if the printers become detached from the machine the permissions will revert on plugin. It would be pretty easy to write a UDEV rule which counteracts this… It’d read something like this:

KERNEL="lp*", RUN+="chmod a+rw /dev/usb/lp*"

Also, note that this is by no means the best way to do this… chmod-ing a device a+rw in a business environment is a BAD IDEA. A better way to do it would be create a script which chmods the device g+rw then changes the ownership of the device to root:(group of users). Then all you’d have to do is add anybody who you want to have access to the printer to that group.

Anyway… Hope this has been useful for some of you.


Slackware Bootsplash Howto

3 02 2009

Hi all. I don’t know about any of you, but the fact that the original bootsplash patch is becoming obsolete and being superceded by sucky… sorry, I mean splashy… really pisses me off. I love the simplicity and speed of bootsplash, and splashy has failed to deliver on almost every front. It’s slow, ungraceful, difficult to make really pretty, and what annoys me more than anything is that the verbose mode is utter crap. Kernel panics will never be easy to diagnose again.

I don’t install bootsplash often enough to know it off by heart, and I find that every time I install Slackware on a new system I want to put a bootsplash on I can never exactly remember how — cue many frustrating wasted hours trying to get it sorted. I’d imagine it’s a problem that I’m not alone in encountering, so for your intellectual enjoyment (and hopefully to help retain your hair’s colour!), here’s a full howto.

NB: If you are a newbie to compiling kernels, creating initramfs images and reconfiguring LILO, then consider seriously practising/reading up on them before attempting this, as you could render your system unbootable.

Step 1: Patch, configure and install the kernel.

You’ll need a working patch for the kernel you’re using. Sometimes a patch from a previous kernel will work, but always patch with the following tags first:

patch --dry-run -p1 < bootsplash-3.1.6-$(uname -r)

This will just test the patch. If you get any HUNK FAILED messages, then DON’T USE IT! Also, if you are trying a patch from a different kernel, then replace $(uname -r) with the patch’s kernel version.

You will now need to configure the kernel using your favourite .config editor. I’m a huge fan of xconfig (type make xconfig in your kernel’s unpacked directory). You will need to turn OFF the existing bootup logo and turn on the bootup splash screen. It’s probably a good idea to make sure you have initrd/initramfs support in there too.

Now compile and install your kernel. If you don’t know how to do this, Eric Hameleers (Alien Bob) has written an excellent guide on his Dokuwiki. Take heed of all of his warnings, as doing this wrong could hose your computer. See you after the KERNEL PANIC.

Now boot up your new kernel.

Step 2: Download, compile and install the splash util.

There are countless copies of the splash utilities scattered around the internet, and the places you’ll find them change regularly, so I can’t give you a direct link, but version 3.0.7 seems to be a pretty good bet, and easy to find.

Once you have downloaded the package, just typing make will result in a huge b0rk-fest. The only binary you need is splash, so just type make splash, and you should be ok. Now copy this into /sbin and that’s step 2 complete.

Step 3: Make your initramfs format initrd.gz

I find this is where the guides all start to tell fibs. They all tell you just to use the splash binary and redirect the output to a file. THIS DOES NOT WORK. The reason being that Slackware now uses an initramfs image for it’s initial ramdisk, which is a compressed cpio archive. Just using this file will not be recognised, and annoyingly there will be no useful pointers to show you what’s wrong.

First off, you’ll want to download a bootsplash from somewhere. Kde-look has some pretty nifty ones. Now create the directory /etc/bootsplash/themes. Put the files you downloaded in here in the format /etc/bootsplash/themes/theme-name/images and themes/theme-name/config.

UPDATE (8/7/2011):

If you are creating your own images to use as a bootsplash, you will need to make sure that they must be in YCbCr 221111 JPEG format, which means that they must use the JPEG file format, YCbCr color space, and subsampling must be set to 2×2, 1×1, 1×1. This is achieved in GIMP by choosing JPG format, and then under Advanced Options, selecting 2×2, 1×1, 1×1 (smallest file) from the Subsampling drop down box. Simple when you know how!

Now to actually create the initramfs. First of all, check for the existence of a file called initrd.gz in your /boot folder. If there is one there, then you should back it up before proceeding, as it will now be blown away. Navigate to /boot and type:

mkinitrd -c -k $(uname -r) -f filesystem on root partition -r /dev/root partition

There will now be a folder called initrd-tree in /boot. This will be the contents of your initrd. Navigate to this folder and use the following command:
splash -s -f /etc/bootsplash/themes/theme-name/config/bootsplash-1024x768.cfg > bootsplash

This has placed some information for the kernel on the location of the bootsplash theme in the cpio archive. You now need to place the bootsplash into the folder in exactly the same directory structure that exists on your filesystem. Create the folder /boot/initrd-tree/etc/bootsplash/themes and copy in the bootsplash theme you downloaded and installed earlier.

To finish off our penultimate step, go to /boot again and type simply mkinitrd to compress the contents of /boot/initrd-tree into the initrd.gz file you will now see in the /boot folder.

Step 4: Reconfigure LILO and reboot.

Ok, we’ve got to the point of no return. You have a working bootsplash enabled kernel and a brilliantly put together initramfs image. Now you’ll need to modify the /etc/lilo.conf section which points at your new kernel as follows:
image = /boot/vmlinuz-custom- # Or whatever your kernel image is called
root = /dev/hda7 # Or whatever your root partition is.
label = Slacksplash # Name it anything you like
initrd = /boot/initrd.gz
append = "splash=silent"

You will also need to configure LILO to boot in the screen mode for whichever resolution and bit depth the splash image is in. You can find a list of VESA screen modes here. You can either use the decimal or hexadecimal values. Lilo will understand both, but make sure you prefix the hexadecimal number with 0x… Here is an example:

# First of all in decimal:
# This is the same as the following in hexadecimal:

If you get the screen depth wrong, all will appear to go fine, but you won’t get a splash image. I have to fiddle with this almost every time I apply a bootsplash!

Once you’ve got it configured, run lilo. I tend to use lilo -c -v as -c speeds up the initial loading of the kernel (compact mode), and -v gives you a whole bunch of useful information to help troubleshoot any problems.

Now reboot, select your kernel from the list and admire all the beautiful colours swirling across your screen.

That’s it… Done. Any questions just leave me a comment.


Madwifi-ng and injection on Slackware 12.0

19 03 2008

Hi guys. Thought I’d pass on some info on getting the Madwifi-ng drivers working with my Atheros 5212 internal wireless card. When I installed them on a base setup (no mods made to Slack), I kept getting a weird error which I couldn’t find anybody else getting. This was that  for Managed mode it worked absolutely without fault, but when I used airmon-ng or wlanconfig to put my card into Monitor mode, it gave me a bunch of errors which said such things as no such device and other blatant lies. A bit more digging led me to it being a problem with udev. In the meantime, I had upgraded my kernel to, but when I recompiled the drivers against my new kernel, it still gave me the same whole bunch of errors. I then went and downloaded udev 118 from here and used upgradepkg to update it. After a quick reboot (not a fan of doing this but I was really tired!), I loaded up Kismet. Not a single error. I then ran airmon-ng start wifi0. No errors! Next – aireplay-ng –test -b $AP ath0. 30/30! 100%! Awesome and win.