For some (smartphone related) project, I need wireless network access to do a proof of concept. In addition, I wanted to be able to work with the laptop also at other places in the house, not only on my desk, and I also wanted to get rid of the network cable. So it was time to get some wireless access point. After some research on the web, I found that the Linksys WRT54GL router had very good ratings. One advantage of this router is that the firmware can be replaced with some open source firmware which adds extended capabilites.

It was really easy to setup the router, yet two special things had to be considered:

• The default router IP address is 192.168.1.1. But in my network, this address is already assigned to the existing primary router. So, the first thing was to connect the WRT54G router to a PC through one of the four normal router LAN ports, and then reconfigure the router address.
• Then, unfortunately the quick start guide only describes how to connect the router to a broadband modem (through the WAN port). When used as access point "only", the approach is a littlebit different: simply connect the router through one of the four normal router ports to the network. There is no crossover cable necessary, the router automatically detects that it is connected to a switch or hub and configures the port accordingly.

After these small problems have been solved, the router could be configured and I was able to test the new cable free world :-)

Since I upgraded to the AMD64 architecture some months ago, I always had the problem that burning CDs did not work anymore. I used a command line like

cdrecord -V gracetime=2 dev=3,0,0 speed=24 -dao -dummy driveropts=burnfree -eject -data test.iso

but burning failed some seconds after the write started.

Now, it seems that I found the solution: with kernel 2.6 and udev, it is not necessary to use the device numbers anymore. Instead, the device file can be used directly, like

cdrecord -V gracetime=2 dev=/dev/cdrw speed=24 -dao -dummy driveropts=burnfree -eject -data test.iso

This also seems to influence the way how cdrecord and the kernel interact, because the write process now does not abort anymore.