The La Fonera 2.0 (FON 2202) comes with
ssh enabled, which isn't a big surprise since it's still in beta and developers are encouraged to develop plugins for the Fonera platform.
Even with
ssh enabled though, the best way to
hack the Fonera, i.e., to replace the currently deployed (very customized) linux distribution with something like DD-WRT or OpenWrt, still is directly accessing the bootloader.
Almost exactly like in previous Fonera versions, the bootloader (RedBoot) waits for a few seconds to be interrupted, before moving on and booting the deployed kernel. The Fonera 2.0 will wait at IP address 192.168.1.1 on port 9000, for no more than 2 seconds, to receive an iterrupting
Control C. Meaning, if a host computer with an assigned IP of something like 192.168.1.254 is connected to the Fonara, issues this command:
echo -e "\0377\0364\0377\0375\0006" >break.bin; sudo nc -vvv 192.168.1.1 9000 < break.bin; telnet 192.168.1.1 9000
and the Fonera gets rebooted, RedBoot will pause the booting process and show
RedBoot> prompt.
If that for whatever reason doesn't work, there is still a way to access and interrupt the bootloader through the internal serial connector, like shown here:
Issuing the following command in OS X's Terminal app,
screen /dev/tty.KeySerial1 9600
rebooting the Fonera, and subsequently pressing
Control C will also interrupt the boot process and grant access to the bootloader prompt.
The output in the terminal looks something like this:
+Ethernet eth0: MAC address xx:xx:xx:xx:xx:xx
IP: 192.168.1.1/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.1.254
RedBoot(tm) bootstrap and debug environment [ROMRAM]
OpenWrt certified release, version 1.1 - built 12:40:38, Sep 3 2007
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Board: FON 2202
RAM: 0x80000000-0x82000000, [0x80040290-0x80fe1000] available
FLASH: 0xa8000000 - 0xa87f0000, 128 blocks of 0x00010000 bytes each.
== Executing boot script in 2.000 seconds - enter ^C to abort
^C
RedBoot>
However, not interrupting the boot process also has its benefits, like being able to capture a complete boot-log like this:
RedBoot Flash Image System
| Command |
Description |
fis create [-b <base>][-l <image length>]
[-s <data length>][-f <flash address>]
[-e <entry>][-r <ram address>][-n] <name> |
Creates an image in FLASH from data in RAM |
| fis delete <name> |
Removes an image from FLASH |
| fis erase -f <flash address> -l <length> |
Erases an area of FLASH |
| fis free |
Shows which areas of FLASH are not in use |
| fis help |
Displays help for FIS commands |
| fis init [-f] |
Initializes FLASH |
| fis list [-c] |
List images in FLASH and information about them
The -c option displays image checksum instead of memory address |
| fis load [-b <base>][-c] <name> |
Loads an image from FLASH to RAM
The -c option displays the image checksum |
Cleaning ...
With full access to RedBoot and its Flash Image System, deleting all but the boot blocks is as simple as issuing the
fis init command.
Here is the protocol:
Just like expected (hoped) the RedBoot bootloader was not removed and the FIS directory and RedBoot config stayed in place as well. However, all Fonera code is now gone and there is no need to hurry now after a reboot.
telnet 192.168.1.1 9000 connects back to RedBoot, which now reports:
87E:0000 - 803:0000 = 7B:0000 = 7,872 KBytes Flash Memory available:
