So Proud of Myself

Wednesday 9. April, 2008

Today I finally managed to repair my A-Link RR24AP(c) adsl-modem. The problem was that the wireless side didn’t function at all because the boot environment of the modem was corrupted. The corruption was my fault as I accidentaly used a wrong power source which wasn’t powerful enough, all I could see was the lan-connection light flickering.

Few weeks ago I contacted A-link’s tech support and they told me to send the modem to their technicians, but I didn’t bother to that as the warranty period had ended quite some time ago.

The modem accepts ssh-connections for controlling it and a linux shell/toolset, busybox. Boot environment configuration can be accessed through /proc/ticfg/env -file. A quick look into it and some knowledge from RouterTech’s forums and the modem’s system log revealed that WLAN_EEPROM-values were missing. I don’t know exactly what these values are but I do know that without them the wireless doesn’t work.

I found a recovery software through the same forums but the program didn’t start. I crashed immediately. I was very disappointed as it was my only hope. As I knew that I needed those WLAN_EEPROM-settings so it came to my mind to take a look on that program with a hex editor (Notepad++ with hex editing plugin, in case you want to know…) and indeed there they were! Apparently it was a template of the eeprom-settings, but still I got my hopes up again!

I didn’t expect this template to work directly which was then confirmed when I tried it. Again the answer was found in RouterTech’s forums. Some other guy had the same problem of missing/corrupted WLAN_EEPROMs and some other guy told him that WLAN_EEPROM8-line contains a hardware specific id in REVERSE order (12 34 56 would become 56 34 12). Modifying that line did the trick! The WLAN-led lit up! I had restored the right WLAN_EEPROMs (WLAN_EEPROM0-WLAN_EEPROM14) and I had a working wireless access point. One problem, though, the modem though that the BSSID was 00:00:00:00:00:00 THAT IS NOT RIGHT! (and only my laptop’s Intel 3945 detected it, my buffalo usb-wlan stick didn’t see anything).

And to the Google we went… it turned out that WLAN_HWADDR0 should be set and contain the MAC-address of the wlan-system.

Now the modem is under testing and seems to run just fine.

(I don’t publish the WLAN_EEPROM-values here because I don’t know if  that would be legal)

Incomplete standards

Saturday 5. April, 2008

My friend does some C programming and many times he has im’ed me about his progress in his projects or other interesting results. This time he complained that his code doesn’t work the same way in Linux as it does in Windows. I’ll demonstrate the problem with the same code he demonstrated the problem to me:

#include <stdio.h>

int main(int argc, char *argv[]) {
int temp = 0;
printf(“%d %d “, temp++, temp++);
printf(“%d\n”, temp);
return 0;
}

What do you expect this little program to do? Does it print something? You’re right but what exactly does it print? well, that depends on what compiler it was compiled on…

WIth University’s Sparc-Solaris gcc-3.0.4 it print 0 1 2, with Ubuntu Feisty’s gcc-4.1.2 and lcc-win32 it will print 1 0 2 and actually lcc-win32 printed the same as did Cygwin’s gcc-4.4.3.

Googling for explanation ended up telling that this case is not defined in standard C so results may vary on every compiler.

I wonder why that hasn’t been defined… For a programmer it should be quite clear that this code should print 0 1 2 but I do understand that this might get bit controversial as you could expect it to print anything from 0 0 1, 0 0 2, and so on to 0 1 2.

(Ha! You might have expected me to write about my lack of morality and standards instead of this…)