August 31, 2008

Attack of the mutant slug from the fourth dimension

I went to buy some parts at my network dealer and they had the Linksys NSLU2 in stock. Wow! I've heard many good things about the NSLU2 but have never had one because they were never available locally. So I bought one immediately.

Loading the Unslung firmware (and voiding the warranty) was relatively easy. One issue I ran into was that eventhough the NSLU2-Linux website and wiki are very complete, they are not always updated to reflect changes in developement, and there are a lot of duplicate pages filled with conflicting information created by different people at different times of the firmware's development process. It is not easy for a newcomer to the NSLU2 "scene" to find the right information to get started.

I didn't have any projects in mind for the NSLU2 when I bought it, but I happened to need a USB printer server and was never able to find a good one. In fact, I was looking at buying some USB-capable wireless routers such as the ASUS WL-520gU and load it with Oleg's firmware to turn it into printer server. So I decided to turn the NSLU2 into a USB printer server by using CUPS.

Which turned out to be a good choice. After running CUPS for a bit, I realized that all the USB print servers I had previously as well as Oleg's firmware use p910nd, which appears to simply forward all data it receives from the LAN directly to the USB port, which causes all kinds of weird issues and random lockups. CUPS, on the other hand, works differently by spooling the files locally then sending them to the printer, which can be seen by the ability to cancel or move jobs directly from the CUPS web interface. So buying the NSLU2 turned out to be a good choice after all.

But after using the NSLU2 + CUPS for an hour "in production", I immediately ran into a new issue. When the USB printer is turned off, or if the NSLU2 is powered on before the printer, the printer appears to be unplugged from the NSLU2. If CUPS receives a new print job at this point, it has no way to turn on the printer by itself, so it just stops the printer queue and holds onto the job, and the web interface returns the error: "Unable to open device file "/dev/lp": No such device". Unfortunately, turning on the printer manually at this point doesn't automatically make CUPS restart the job queue, and I had to manually restart the printer from the web interface or from the shell.

A lot of googling and reading the hopelessly confusing wiki all seem to point to one conclusion: I need to have the hotplug package, which doesn't seem to be available in Unslung. So while I was contemplating the installation of SlugOS, the printer suddenly came to life and the stuck print job came out. Magic! So while it's not like having a hotplug event that automatically resumes the print job immediately, at least it resumes, and everyone is happy.

Update: Turns out that the Canon printers we use have an auto-power on feature that turns the printer on when it receives a print job. It just happens the one printer I used for testing the NSLU2 and CUPS earlier was a new printer just taken out of the box and had not yet had the auto-power on function enabled. When the auto-power on feature is enabled, the printer automatically works without CUPS complaining or giving any errors. Yay!

1 comment:

Eric said...

SlugOS/BE has a lot more features than UnSlug. Of course it's more stripped down too and you'll need to add what you want. However 'udev' is available for it, which handles hotplug events.

Also, canon printers that go to sleep can be configured by first connecting them to a windows PC and with the windows software driver, you can change the sleep time...even change it to off, then write the settings directly to the printer. Most canon printers by default have this turned on to around 30-60 minutes.