WRT54GL router looses MAC address upon reboot?

My WRT54GL router had stopped working today morning and I had to restart it. After that I didn't get the DNS servers and as a result couldn't connect to the Internet.

I have to clone my PC's MAC to the router so that the cable company allows me access to the Internet. Upon accessing the router admin page, I realized that this setting had reverted. Once I cloned the MAC again, I could get a DNS server and connect to the Internet.

I was surprised by this behavior - I know the router has problems under heavy traffic (probably that is why it stopped working in the first place) but I would have assumed that the settings were in some NVRAM and was safe from poer cycles.

At some point I should try the open source firmware for this router. Since it has a Linux kernel released under GPL, there is a lot of cool stuff that can be done to improve it.

Linux system calls - how they work

Very nice article here - by Alessandro Rubini

the simplest Linux kernel module

I just wrote the simplest possible kernel module. Here it is (hello_world.c):

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

MODULE_LICENSE ("GPL");

static int __init hello (void) {
printk (KERN_ALERT "Hello World!\n");
return 0;
}

static void goodbye (void) {
printk (KERN_ALERT "Good Bye!\n");
}

module_init(hello);
module_exit(goodbye);

This is taken from the Network Security Tools, excellent book for hackers. You can build the module by 1) creating a Makefile with this line: obj-m +=hello_world.o
2) running make -C /usr/src/linux-`uname -r` SUBDIRS=$PWD modules

The module will be called hello_world.ko and you can load it by becoming root and doing

insmod ./hello_world.ko

This should print "Hello World" if you're doing this from a console (not X), but if you're using X, you should see this message logged in /var/log/messages

You can unload the module by doing (as root)

rmmod hello_world

Again, if you're on X, the "good bye" message will be in /var/log/messages
Now I just have to find the time to get a proper kdbg patch...

Suse on wireless

Just installed my Airlink wireless card on Suse. I used ndiswrapper and the WinXP drivers that came on the CD.
I could ping the wireless card, iwconfig showed the access point etc, but I couldn't connect to the internet through wireless.
A post from otisthegbs here helped me in getting dhclient to get a connection through the wireless card. I reproduce below:


the way SuSE uses its dhcp client is a real bitch. I bet that if you ps -aux grep ifdhcp you notice that you'll have multiple instances of it, and since those daemons are running they constantly screw up the default route. I had the exact same problem as you. What I did was downloaded dhclient, which is part of the dhcp package at ISC, and told those startup daemon to go to hell.Then you can just "sudo dhclient " whenever you need a IP


I had two dhcpd processes running. I killed both and ran dhclient wlan0 and after that I could connect to the internet through wlan0.

Suse 10.1 - is this what Vista should look like?

After seeing the XGL magic in Suse 10.1, I really must try Vista.
I installed Suse 10.1 over the weekend as I had heard of the XGL magic. XGL was not installed by default, and I used yast2 to get the right packages installed.

I could then get gnome-xgl-settings to work, but it couldn't enable XGL as my graphics card (NVIDIA GEForce FX5200) was not supported. This post suggested that I download the driver from nvidia.

The package I downloaded from nvidia actually built a kernel module, installed the driver, prompted me to log out and back again, and voila, I had XGL.

[BTW, I couldn't run the install while I had X running, so I simply changed the default run level in /etc/inittab to 3, rebooted and installed from the console]

Lots of fun using the 3D desktop!

debugging the linux kernel

I'm taking baby steps today, debugging the kernel.
This seems a very useful resource.

I tested the com ports between the 2 machines using the instructions there and it works great.

A tiny missing step that would be useful to a newbie like me unfamiliar with patching the kernel:

Under "Applying the kgdb patch", you need to first go into the linux directory before executing the patch command. So between 1 and 2, there has to be a step:

cd {$BASEDIR}/linux-2.6.7

Also the path to the patches is missing a sub-dir. The patches are all unzipped into {$BASE_DIR}/patch-kgdb/linux-2.6.7-kgdb-2.2/ so the patch commands from 2 to 7 should read this way:

patch -p1 < ${BASE_DIR}/patch-kgdb/linux-2.6.7-kgdb-2.2/core-lite.patch

Snag 2:

I realized I needed the qt-devel package to do 'make xconfig' - this is fully graphical. So I decided to do make menuconfig (which I've done before, and which uses a text based menu). Then I ran into this compiler error. By following the simple patch (remove static from declaration of 'current_menu'), I could proceed with the build. Now I had the menu where I could make the kernel selections - progress!

Snag 3:

I realized that 2.6 has been compiled with GCC 3 and does not compile with GCC 4 (which is what most newer machines have). I decided to be macho and 'fix' the kernel code to get the compiler to sing. Still going strong after 1 day...
This is a good article on the GCC 4.0 changes that affect Linux 2.6.7 as well.

Snag 4:

I managed to fix all the compiler / linker errors (they were due to the stricter way GCC 4.0 treated inline and static keywords). I transfered the image over to the test machine, changed grub, but it wouldn't boot -problem mounting the file system. Upon investigating I found that linux needs the initrd image to boot (the initrd image loads the drivers in RAM). But to build the initrd image, you need to install the modules as well. (mkinitrd that you use to make the initrd image needs the kernel version and it looks inside /lib/modules/ for the drivers). Now since I didn't have the modules installed on the test machine for this version of the kernel, I just specified a valid kernel that was on the box to mkinitrd, and it successfully built me an initrd image. Now I moved it over to /boot, edited grub to note that and rebooted. No joy! It was still failing to mount. Over the weekend, I was chatting with a good friend who is now hacking away in the Linux kernel (he was previously an engineer in the Windows kernel) and he said that this is probably because the driver versions are being checked by Linux. So I decided to install the modules on the dev machine, make a correct initrd image and copy it over to the test machine. This time it actually booted!

Here is where you can read how to do a regular kernel compilation (for the modules install part)

Snag 5:

SEGSEV in the kernel! Well I was happy. We came this far and here's my chance to look at some kernel code, see what's going wrong.

Here's the immediate output from gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0xc03051db in psmouse_interrupt (serio=0xc048cde0, data=250 '\uffff', flags=0,
regs=0x0) at drivers/input/mouse/psmouse-base.c:206


And here is line 206 from psmouse-base.c:

rc = psmouse->protocol_handler(psmouse, regs);

So it seems that somehow the protocol handler for the mouse is not set. This is a USB mouse, so perhaps I forgot to set an option in make menuconfig...

hacking inside the grub prompt

Yesterday, I was setting up Linux on a new PC and went ahead with a custom partition table using druid. I didn't set up the /boot partition and as a result the grub configuration file (/etc/grub.conf) was incorrect. Then grub stopped at the grub prompt (thus giving me a chance to temporarily correct the problem)

I found this article very helpful in telling grub what I wanted, so that it proceeded with finding the Linux image and loading it.

Incidentally, this machine had a SATA drive, and ata_piix used to complain and kernel panic at boot, I removed the SSC pin (spread spectrum clocking feature) and it booted fine after that.