I had a spare Aztech DSL605EW which was laying about. So I got to trying out firmware routertech.org (some brilliant minds and great resources.) Eventually I managed to “brick” the router, i.e., the lights on the front panel would turn on when the router was powered up, do its usual initialization dance, but the PC would not get an IP address. WiFi SSID was visible, but I did not have the WEP key to connect to it. I realized I must have used a version of the firmware that was not able to handle the 1350A ethernet switch.
Next tried Adam2App.exe to connect to the bootloader, it connected after some attempts to get the timing right (I figured i need to click on the “Retrieve/Assign IP Address” button exactly at the 9th second after router powerup to connect consistently everytime.) I was then able to load the correct firmware on the router and I was then able to connect to the web interface. I then discovered that the RouterTech firmware only allowed ADSL as the WAN connection interface. The Internet connectivity to home is Ethernet over GPON, this meant that I would not be able to use this router at home if I ever wanted to.
When I discussed my dilemma with Troy, he volunteered to lend me his Aztech 605EW with the firmware that allowed Port4 of the Ethernet switch to be used as a WAN interface. So, now it was time to extract the firmware from Troy’s router. After some poking around here’s what I did to extract the firmware:
1. Started up a TFTP Server on my PC ( I used TFTPD32 by Ph. Jounin http://www.jounin.net/tftpd32_download.html)
2. Connected up my PC (Manually configured IP Address : 192.168.1.21) and the router and telneted to the router (default UserID : root Password : admin)
BusyBox on localhost login: root Password: DSL Modem CLI Copyright (c) 2004 Texas Instruments, Inc. cli> shell Starting /bin/sh Type exit to return to the CLI BusyBox v0.61.pre (2009.04.08-03:17+0000) Built-in shell (ash) Enter 'help' for a list of built-in commands. # cd /var/tmp # cat /dev/mtdblock/4 > TroysFirmware.bin # tftp -p -l TroysFirmware.bin 192.168.1.21 #
Now that the firmware was on my PC, I tried loading the dumped firmware using the web interface of my router. It aborted with a checksum failed error message, not entirely unexpected ;-). The only choice was to try and load this firmware using the bootloader interface. Back to the the Adam2App to connect to the bootloader selected the relevant settings (indicated by the arrows in the screenshot below) and used the “Download” button to select the firmware extracted earlier. A few minutes later it was up and running!
I came by a Kingston SSD the other day. Installed in a Lenovo T61 with Lucid Lynx. Performance is great!
Strange thing, however, is the SSD would not respond to a warm-restart and the T61 would report a HDD error during POST; cold starts were fine. After some messing around trying to figure out a solution, I changed the SATA setting from AHCI to Compatibility mode. Things started working fine from there onwards although I’m not pleased since its a workaround.
Last morning the Internet connection through my Draytek 2910 at home failed. Usually restarting the Draytek would fix it. This time it refused to come back up. Then I connected a PC directly to the GPON device and created a PPPoE dialer on WinXP and the connection came up in a flash! That’s strange, I thought. Plugged the DrayTek back and tried changing the MTU, the PPP authentication and some other parameters. No luck.
Had a chat with Troy about this strange behaviour, he was also stumped.
The ISP tech came over this morning and meddled around with the device and no luck. I suggested that he connect the ISP standard router and configure it with my PPPoE parameters. He did and the link came up! So he left with the factually correct but useless statement that “something was wrong with the Draytek”
Next I wiresharked the line to see what was going over the wires. I noticed the PADI was going out with the display name I’d configured on the Draytek for this connection! So obviously the so-called Display Name was NOT just that… it was being actively used as the service name in the PPPoE conversation.
Troy called me just then, after some discussion with his cronies and suggested that I remove the display name. The wireshark log confirmed Troy’s statement and figured that this must be the reason. Blanked out the Display Name in WAN Setup and… I had working Internet!
So now, its clear that something changed at the ISP end (although they vehemently denied it), since this device was working fine with these parameters till early last morning.
Came across this interesting article on MagicJack at Digital Offensive. Got to try it out soon.
I was building MadHatter’s T42 with WinXP SP3 the other day. All the drivers installed easily from Lenovo’s support site (always felt it was comprehensive) except for the device ACPI\ATM1100\4&61F3B4B&0.
This turned out to be the Atmel Trusted Platform Module device for which the driver can be downloaded at http://www-307.ibm.com/pc/support/site.wss/MIGR-58054.html
We removed the intercooler fan from the Smart, a quick 3 minute job, sprayed it generously with WD-40 and spun it by hand till it worked loose. All those months (years, maybe) of lying unused and in the elements had taken its toll on the bearings.
Plugged it back into the Smart’s electrics, manually jumpered the intercooler relay and the fan spun initially with slight resistance. So we opened up the fan, cleaned and lubed the bronze bushing, cleaned the brushes and installed everything back into the car. All’s well that runs well.
Now Kay’s grinning from ear to ear, happy that this operation saved him a tidy sum of money!
Kay got himself an old Smart ForTwo. It was flat-bedded from the original owner’s place to Kay’s. We cleaned, changed all the fluids and got it running over the weekend, thanks in no small measure to Evilution. This site has heaps of information about Smarts and is a must read for the enthusiast.
Five minutes into the test drive the a/c stopped cooling without warning. My initial reaction was “Ok, blown fuse”. Kay said the refrigerant was low. So we took it to a local wrench assuming the refrigerant was low. He did a quick check and confirmed it was fine. So then we concluded it was an electrical problem (should have stuck with my gut feel.) Pulled out the secondary fuse box (under the driver’s seat, i.e., the left side seat.) It was easy to locate after a quick look at FQ101’s engine fuses page (another brilliant Smart specific site!) Sure enough, the 15A fuse powering the electromagnetic clutch on on the a/c compressor was blown. Replaced it with a new 15A fuse and started up the car. POOF! Blown again.
Then after reading and digesting FQ101’s page on fuses, I realized that the intercooler’s fan was also powered by the same fuse. Hmmmm… could it be the fan? Ran down to the Smart and tried to spin the fan by hand. Almost completely seized. Ok! So there’s the culprit. Pulled out the intercooler relay from the secondary fuse box. Replaced the fuse again, fired up the engine and a/c working fine again. Drove around for about 25km and all is well.
Next step is to pull out the fan, replace it or get it serviced. This can wait till I get back from vacation.