« Previous | Next»

La Fonera: A better way to enable RedBoot via Telnet / Ethernet (safely) [HowTo]

Posted by coldtobi | 21 Jan, 2008, 02:11

Booting La Fonera -- Redboot Bootloader

RedBoot is the bootloader used in the La Fonera. As this bootloader can not only operate over RS232, it also can be configured to offer a simple -- but powerful -- dedicated shell over telnet / Ethernet.  This is also true for the La Fonera, but has only one  problem: It has no IP configured, therefore you cannot use it. We'll gonna change that now!

Update: Now, 2014, the original locations of the files are gone. Please see the bottom of the post for an solution.


First of all, you might ask, why you really want to enable RedBoot on your LaFonera?

Well, enabling Redboot is not needed for daily use -- especially if you want to use it as FON dictates you.
But it might be helpful,

  • if you want to take a closer look under the hood, or

  • if you want another convenient way to unbrick it  -- without the need for a serial connector or opening it --.

  • You want a "safety hook", in case SSH somehow gone and you have to downgrade the La Fonera.

  • Also, If you want to install alternatives like OpenWRT, you gonna love it. (But this is a more serious surgery).

(Please note -- in case you came here for unbricking instructions -- you'd needed to enable RedBoot before bricking it. Sorry.)

Okay, for all these, you could can also use the RS232 found on the Fonera: La Fonera's "standard" Redboot is only configured to use a serial connection.But for that you'll have to have a RS232-to-TTL-Converter ready and you need to open the case.
But isn't ethernet far far more convenient?

Another Solution
or: "There are many instructions on the net how to enable RedBoot via Ethernet."

Current
instructions to enable RedBoot found on the net have one major drawback:
There is a state, where you have to reboot into a broken "La Fonera". Well, reboot is the wrong word for it, as it actually will not boot.

Why does these break?

To understand, why these "have to" break the box , you have to understand the following facts about flash resp. the LaFonera. First lets take a look a the "flash memory" layout used in the box.

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "RedBoot"
mtd1: 006f0000 00010000 "rootfs"
mtd2: 00570000 00010000 "rootfs1"
mtd3: 00010000 00010000 "config"
mtd4: 000b0000 00010000 "vmlinux.bin.l7"
mtd5: 0000f000 00010000 "FIS directory"
mtd6: 00001000 00010000 "RedBoot config"
mtd7: 00010000 00010000 "board_config"

For the Redboot-Telnet-Configuration, only mtd6 is relevant. However, mtd6 is also affected.

  • mtd5 contains the FIS-Directory. This like a "Partition Table" on a regular PC. Without that, RedBoot does not know what to load and boot. 

  • mtd6 contains the configuration for the bootloader. This is the "partition" where the IP-configuration is missing. This is the partion, which has to be written to enable RedBoot.

Why these two section are affecting each other, and to see the problem with the current solutions, you have to know two facts about Flash memory:

  1. Flash cannot be rewritten without prior erasing it. (To be precise: Flash can only written from "ones" to "zeros", not vice versa.)

  2. Flash is organized in sectors, and can only be erased "sector wise". The sectors are multiplies of the erasesize, and must also be aligned to a mulitple of this erasesize.

Unfortunately, the RedBoot-Config and the FIS-Directory share one sector, so "2" is violated here: Rewriting the RedBoot-Config sacrifices the FIS-Directory. Rebooted in this state, RedBoot won't know what to do next and panics while it waits for getting its FIS-Directory repaired -- as a paper-weight.

If you don't have a crossover cable, an ethernet switch/hub or one of these new ethernet cards with autosensing capability, you won't be able to repair. Fonera own autosensing support won't work in RedBoot, so you need one of the above to regain access. Usually with modern ethernet-hardware, luck is on your side, and you can boot into RedBoot and manually repair the FIS-Directory.

But with my method, this is not necessary anymore. It still might be, that you cannot access RedBoot because of the requirements, but you'll have a working box in this case.

But why go into troubles, if you can avoid them all together?  My method uses something, the other missed: You can indeed, reprogram a flash without erasing it: You just have to make sure, that section to be changed have not been written to after they had been erased: Remember, "1s" are "erased", "0" are programmed. As long as the memory contains only "1s", you can program the data into it.

So basically, we'll gonna erase the block and then program the to partitions individually avoiding erasing it in between.

So much for the theory 

DANGER, WILL ROBINSON, DANGER!

As I claimed before, my method is more safe. However, as the flash is gonna reprogrammed, please don't miss the word of warning: There is always a change that my instructions won't work in your configuration, missed a thing or just earth rays fried your box. So, as usually, take this disclaimer: If this breaks your box, you own both parts, and I won't buy you a new one. You have been warned.

Please make sure, that you read through all instructions at least once before starting executing them. Only follow them if you are confident.

As I sketched before, my version is safer, but not bullet-proof. The improvement is, that there is no point where you need to *intentionally* reboot into a broken system. Nothing more. There is still a point, where for example  a power-loss could be fatal. So you better crosscheck if the power plug is securely in and maybe you put it out of reach of anyone how might unplug it.

The HOW TO 

Requirements

For this enhancement, you need

  1. A La Fonera
  2. SSH enabled to it.
  3. La Fonera setup for net-access (not really needed, but allows us to use wget the right files directly)


How To Enable It

0. Make a backup. (optional)

On the Fonera, run

cd /dev/mtd
for f in *ro; do echo -n "processing $f."; cat $f | gzip >/tmp/$f.gz; echo " Done."; done
scp /tmp/*.gz <your_user>@<host>:

This will take some minutes, as the Flash is quite slow. After is finished, you have to bring to a safe place.
The example scp it to your host computer. Just make sure to change the command as needed.
Also a good idea would be to unpack the files at the host and compare the md5sums to avoid any undetected errors.

1. Patch the kernel
As laid out before, the mtd5 and mtd6 share one sector. The stock linux kernel does detect this and refuses to mount it write enabled. This is not without reason, as laid out in the theoretical section: Writing one screws the other. As this also prevents us to update the configuration, we have to flash a special kernel crafted without that safety feature. So the first step in this how to is flashing a new kernel. (BTW, if the link is down, please tell me.)

To do the first step, execute these commands: This will download a kernel package and calculate the md5 sum. Please verify the md5 sum with the output shown below: You might ending up flashing a 404-error or something else. Both's probably bad. 

But be warned that the "mtd" command can brick the La Fonera if interrupted!

root@OpenWrt:~# cd /tmp
root@OpenWrt:~# wget http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
Connecting to fonera.info[62.81.199.144]:80
openwrt-ar531x-2.4-v 100% |*************************************|   512 KB    00:00 ETA:00 ETA
root@OpenWrt:~# md5sum openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
38109a348942c00f633eacbf423691b5  openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
root@OpenWrt:~# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
Unlocking vmlinux.bin.l7 ...
Erasing vmlinux.bin.l7 ...
Writing from openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma to vmlinux.bin.l7 ...  [w]
root@OpenWrt:~# sync; reboot


Please be patient. Some of the commands might take some minutes to complete. Lets use the break for some advertising ;-)

(BTW, as asked: vmlinux.bin.l7 is the device name for the mtd.) 

_ASIP_ 

The last command reboots the fonera, after some minutes it will up again with the modified kernel.


2. Prepare for the configuration update
Now, the hot part is approaching: To enable the Telnet, we have to update the "mtd6" partition. But to avoid screwing up mtd5 at the same time, we have first to prepare for that:

root@OpenWrt:~# cd /tmp
root@OpenWrt:~# cp /dev/mtd/5 /tmp/mtd5
root@OpenWrt:~# cp /dev/mtd/6 /tmp/mtd6
root@OpenWrt:~# wget http://fonera.info/camicia/out.hexConnecting to fonera.info[62.81.199.144]:80
out.hex              100% |*************************************|  4096       00:00 ETA:-- ETA
root@OpenWet:~# md5sum out.hex
d5a5ee5817da231684c6198801b5cb1f  out.hex


With these commands, backup of the FIS Directory is stored in /tmp. And also, we download the file out.hex, a specially crafted RedBoot-Config. In this file, the only settings are the ip-address RedBoot should use for connection and the startup-delay is increased to 10 seconds: This is the time it will listen for an incoming telnet session.

The last command is only for additional safety: please check, if the md5 is correct. If a wrong file (for example a 404 -- file not found) is used as RedBoot-Config, changes are good that you'll buy a new Wireless Router soon. If the numbers are different  to my example, diff the hexdumps: If the downloaded file is correct, it should be different only by few, maybe 10 bytes.

3. To Brick Or Not To Brick
Now again, a more sensible step. This time, we gonna erase the sector containing the FIS and the Red-Boot-Configuration, mtd5 and mtd6.  
As you know, the can only be erased together, we have to avoid erasing them after one of the others has been written.
Here are the commands to execute. Please make sure to also read the explanation below before acutally executiing them, as this is also an critical section.

root@OpenWrt:~#mtd erase "FIS directory"
Unlocking FIS directory ...
Erasing FIS directory ...
root@OpenWrt:~#cat mtd5 >/dev/mtd/5
root@OpenWrt:~#cat out.hex >/dev/mtd/6
root@OpenWrt:~#sync
root@OpenWrt:~#md5sum out.hex /dev/mtd6 mtd5 /dev/mtd5
d5a5ee5817da231684c6198801b5cb1f  out.hex
d5a5ee5817da231684c6198801b5cb1f  /dev/mtd/6
2d5c82c2a7785e65640199987000cee5  mtd5    
2d5c82c2a7785e65640199987000cee5  /dev/mtd/5

The first command erases the sector containing mtd5 and mtd6. To check yourself, you can hexdump /dev/mtd/6 and see, that is is all 0xff -- erased flash. To actually write the data, "cat"s are used, as they do not trigger erasing the flash before -- in contrast to mtd. The first cat writes the FIS, and the second is for the configuration. As syncin' won't hurt, this is done in the next step. (If you get an "read only error", please make sure that you really updated the kernel.)

The last command then is only for verification purpose -- it is better to make sure that the md5s of the are matching to the files. So you expect here to have out.hex and /dev/mtd6 the same md5s, as well as mtd5 and /dev/mtd5.

If something went wrong, please retry -- try also switching the order of writing: first write mtd/6 first and then mtd5. If it still does not work, do in no circumstance try to fix this with a reboot, as this will it be then! Retry as often you want, the flash will not wear -- at least not before completing 10,000 tries.

If that won't work, please follow this recovery strategy to at least having a change to boot to RedBoot and then manually reconfigure it.  

#Recovery strategy if something went wrong.
#1. KEEP CALM! Panic will not help and tends for actions making things worse
#2. Read the instructions and follow them
#3. If this won't help, do not reboot or power down the La Fonera while you are seeking for help on the net.
# This command will write the RedBoot Config with the mtd command. Unfort. the FIS will be gone afterwards, but you
# have an enabled redboot for recovery. See e.g the OpenWrt-Wiki for details.
mtd -e "RedBoot config" write out.hex "RedBoot config"
# check the md5sum of the /dev/mtd6, it should be the same as for out.hex
# then you can reboot,  but be aware that you have to recover! It will not boot to linux!

(The recovery should is basically the "traditional" method. It is unlikely that you gonna need it.)    

4. Test RedBoot (optional, but recommended)
After the reconfiguration, it is safe to reboot. Please reboot using the command and not by replugging the box. This is to make sure that all filesystem buffers are indeed synced and flushed to the NV-RAM.

After rebooting, you can power down the Fonera, as now you have to prepare your PC for the final test. I assume that you are using Linux, so the commands for reconfiguring are. (You'll need root privileges for that). Don't forget to adapt the lines to your setup. On mine, eth0 is the used network adapter. As the new redboot configuration will listen on the ip address 192.168.1.254, we have to setup the interface to a address in this subnet. For example, you can use

ifconfig eth0 192.168.1.100/24 up

As it listens only 10 seconds, we prepare a small script. (Note, that you won't use root anymore, my dear Windows users!) So in your favorite console, type this command (NB: this is only one line!) to detect the RedBoot and then inject the ^C in time. 

while true; do fping -t 200 192.168.1.254 && break; done; sleep 5;\
echo -e "\x3" | nc -w 1 -vvv 192.168.1.254 9000 ; \
telnet 192.168.1.254 9000

By the way, the sleep seems necessary, as without netcat tries to connect before the port is opened.
Press enter to start the script, and power up the fonera. You'll get:

192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is alive
== Executing boot script in 8.260 seconds - enter ^C to abort
^C
RedBoot> RedBoot> Trying 192.168.1.254...
Connected to 192.168.1.254.
Escape character is '^]'. 
 

So, look around, for example help. Please note, that there are commands which actually can cause harm to the La Fonera. Some safe commands are "help", "fconfig -l", "version" or "fis list" to name some. To quit from RedBoot, you can also use a command: "reset". Or you just pull the plug. (PS: If you are not familiar with telnet, you issue the escape character ^] by Ctrl+"]"; followed by enter and then "quit" exits telnet.)

 

[Update February 2014]

The Internet does not forget... Usually. This also true here: The domains stop to exists, there files are not there anymore.

However, they can still be found:

1) http://www.dd-wrt.com/wiki/index.php/La_Fonera_Flashing has two working links:

 

Booting La Fonera -- Redboot Bootloader

RedBoot is the bootloader used in the La Fonera. As this bootloader can not only operate over RS232, it also can be configured to offer a simple -- but powerful -- dedicated shell over telnet / Ethernet.  This is also true for the La Fonera, but has only one  problem: It has no IP configured, therefore you cannot use it. We'll gonna change that now!

Update: Now, 2014, the original locations of the files are gone. Please see the bottom of the post for an solution.


First of all, you might ask, why you really want to enable RedBoot on your LaFonera?

Well, enabling Redboot is not needed for daily use -- especially if you want to use it as FON dictates you.
But it might be helpful,

  • if you want to take a closer look under the hood, or

  • if you want another convenient way to unbrick it  -- without the need for a serial connector or opening it --.

  • You want a "safety hook", in case SSH somehow gone and you have to downgrade the La Fonera.

  • Also, If you want to install alternatives like OpenWRT, you gonna love it. (But this is a more serious surgery).

(Please note -- in case you came here for unbricking instructions -- you'd needed to enable RedBoot before bricking it. Sorry.)

Okay, for all these, you could can also use the RS232 found on the Fonera: La Fonera's "standard" Redboot is only configured to use a serial connection.But for that you'll have to have a RS232-to-TTL-Converter ready and you need to open the case.
But isn't ethernet far far more convenient?

Another Solution
or: "There are many instructions on the net how to enable RedBoot via Ethernet."

Current
instructions to enable RedBoot found on the net have one major drawback:
There is a state, where you have to reboot into a broken "La Fonera". Well, reboot is the wrong word for it, as it actually will not boot.

Why does these break?

To understand, why these "have to" break the box , you have to understand the following facts about flash resp. the LaFonera. First lets take a look a the "flash memory" layout used in the box.

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "RedBoot"
mtd1: 006f0000 00010000 "rootfs"
mtd2: 00570000 00010000 "rootfs1"
mtd3: 00010000 00010000 "config"
mtd4: 000b0000 00010000 "vmlinux.bin.l7"
mtd5: 0000f000 00010000 "FIS directory"
mtd6: 00001000 00010000 "RedBoot config"
mtd7: 00010000 00010000 "board_config"

For the Redboot-Telnet-Configuration, only mtd6 is relevant. However, mtd6 is also affected.

  • mtd5 contains the FIS-Directory. This like a "Partition Table" on a regular PC. Without that, RedBoot does not know what to load and boot. 

  • mtd6 contains the configuration for the bootloader. This is the "partition" where the IP-configuration is missing. This is the partion, which has to be written to enable RedBoot.

Why these two section are affecting each other, and to see the problem with the current solutions, you have to know two facts about Flash memory:

  1. Flash cannot be rewritten without prior erasing it. (To be precise: Flash can only written from "ones" to "zeros", not vice versa.)

  2. Flash is organized in sectors, and can only be erased "sector wise". The sectors are multiplies of the erasesize, and must also be aligned to a mulitple of this erasesize.

Unfortunately, the RedBoot-Config and the FIS-Directory share one sector, so "2" is violated here: Rewriting the RedBoot-Config sacrifices the FIS-Directory. Rebooted in this state, RedBoot won't know what to do next and panics while it waits for getting its FIS-Directory repaired -- as a paper-weight.

If you don't have a crossover cable, an ethernet switch/hub or one of these new ethernet cards with autosensing capability, you won't be able to repair. Fonera own autosensing support won't work in RedBoot, so you need one of the above to regain access. Usually with modern ethernet-hardware, luck is on your side, and you can boot into RedBoot and manually repair the FIS-Directory.

But with my method, this is not necessary anymore. It still might be, that you cannot access RedBoot because of the requirements, but you'll have a working box in this case.

But why go into troubles, if you can avoid them all together?  My method uses something, the other missed: You can indeed, reprogram a flash without erasing it: You just have to make sure, that section to be changed have not been written to after they had been erased: Remember, "1s" are "erased", "0" are programmed. As long as the memory contains only "1s", you can program the data into it.

So basically, we'll gonna erase the block and then program the to partitions individually avoiding erasing it in between.

So much for the theory 

DANGER, WILL ROBINSON, DANGER!

As I claimed before, my method is more safe. However, as the flash is gonna reprogrammed, please don't miss the word of warning: There is always a change that my instructions won't work in your configuration, missed a thing or just earth rays fried your box. So, as usually, take this disclaimer: If this breaks your box, you own both parts, and I won't buy you a new one. You have been warned.

Please make sure, that you read through all instructions at least once before starting executing them. Only follow them if you are confident.

As I sketched before, my version is safer, but not bullet-proof. The improvement is, that there is no point where you need to *intentionally* reboot into a broken system. Nothing more. There is still a point, where for example  a power-loss could be fatal. So you better crosscheck if the power plug is securely in and maybe you put it out of reach of anyone how might unplug it.

The HOW TO 

Requirements

For this enhancement, you need

  1. A La Fonera
  2. SSH enabled to it.
  3. La Fonera setup for net-access (not really needed, but allows us to use wget the right files directly)


How To Enable It

0. Make a backup. (optional)

On the Fonera, run

cd /dev/mtd
for f in *ro; do echo -n "processing $f."; cat $f | gzip >/tmp/$f.gz; echo " Done."; done
scp /tmp/*.gz <your_user>@<host>:

This will take some minutes, as the Flash is quite slow. After is finished, you have to bring to a safe place.
The example scp it to your host computer. Just make sure to change the command as needed.
Also a good idea would be to unpack the files at the host and compare the md5sums to avoid any undetected errors.

1. Patch the kernel
As laid out before, the mtd5 and mtd6 share one sector. The stock linux kernel does detect this and refuses to mount it write enabled. This is not without reason, as laid out in the theoretical section: Writing one screws the other. As this also prevents us to update the configuration, we have to flash a special kernel crafted without that safety feature. So the first step in this how to is flashing a new kernel. (BTW, if the link is down, please tell me.)

To do the first step, execute these commands: This will download a kernel package and calculate the md5 sum. Please verify the md5 sum with the output shown below: You might ending up flashing a 404-error or something else. Both's probably bad. 

But be warned that the "mtd" command can brick the La Fonera if interrupted!

root@OpenWrt:~# cd /tmp
root@OpenWrt:~# wget http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
Connecting to fonera.info[62.81.199.144]:80
openwrt-ar531x-2.4-v 100% |*************************************|   512 KB    00:00 ETA:00 ETA
root@OpenWrt:~# md5sum openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
38109a348942c00f633eacbf423691b5  openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
root@OpenWrt:~# mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
Unlocking vmlinux.bin.l7 ...
Erasing vmlinux.bin.l7 ...
Writing from openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma to vmlinux.bin.l7 ...  [w]
root@OpenWrt:~# sync; reboot


Please be patient. Some of the commands might take some minutes to complete. Lets use the break for some advertising ;-)

(BTW, as asked: vmlinux.bin.l7 is the device name for the mtd.) 

_ASIP_ 

The last command reboots the fonera, after some minutes it will up again with the modified kernel.


2. Prepare for the configuration update
Now, the hot part is approaching: To enable the Telnet, we have to update the "mtd6" partition. But to avoid screwing up mtd5 at the same time, we have first to prepare for that:

root@OpenWrt:~# cd /tmp
root@OpenWrt:~# cp /dev/mtd/5 /tmp/mtd5
root@OpenWrt:~# cp /dev/mtd/6 /tmp/mtd6
root@OpenWrt:~# wget http://fonera.info/camicia/out.hexConnecting to fonera.info[62.81.199.144]:80
out.hex              100% |*************************************|  4096       00:00 ETA:-- ETA
root@OpenWet:~# md5sum out.hex
d5a5ee5817da231684c6198801b5cb1f  out.hex


With these commands, backup of the FIS Directory is stored in /tmp. And also, we download the file out.hex, a specially crafted RedBoot-Config. In this file, the only settings are the ip-address RedBoot should use for connection and the startup-delay is increased to 10 seconds: This is the time it will listen for an incoming telnet session.

The last command is only for additional safety: please check, if the md5 is correct. If a wrong file (for example a 404 -- file not found) is used as RedBoot-Config, changes are good that you'll buy a new Wireless Router soon. If the numbers are different  to my example, diff the hexdumps: If the downloaded file is correct, it should be different only by few, maybe 10 bytes.

3. To Brick Or Not To Brick
Now again, a more sensible step. This time, we gonna erase the sector containing the FIS and the Red-Boot-Configuration, mtd5 and mtd6.  
As you know, the can only be erased together, we have to avoid erasing them after one of the others has been written.
Here are the commands to execute. Please make sure to also read the explanation below before acutally executiing them, as this is also an critical section.

root@OpenWrt:~#mtd erase "FIS directory"
Unlocking FIS directory ...
Erasing FIS directory ...
root@OpenWrt:~#cat mtd5 >/dev/mtd/5
root@OpenWrt:~#cat out.hex >/dev/mtd/6
root@OpenWrt:~#sync
root@OpenWrt:~#md5sum out.hex /dev/mtd6 mtd5 /dev/mtd5
d5a5ee5817da231684c6198801b5cb1f  out.hex
d5a5ee5817da231684c6198801b5cb1f  /dev/mtd/6
2d5c82c2a7785e65640199987000cee5  mtd5    
2d5c82c2a7785e65640199987000cee5  /dev/mtd/5

The first command erases the sector containing mtd5 and mtd6. To check yourself, you can hexdump /dev/mtd/6 and see, that is is all 0xff -- erased flash. To actually write the data, "cat"s are used, as they do not trigger erasing the flash before -- in contrast to mtd. The first cat writes the FIS, and the second is for the configuration. As syncin' won't hurt, this is done in the next step. (If you get an "read only error", please make sure that you really updated the kernel.)

The last command then is only for verification purpose -- it is better to make sure that the md5s of the are matching to the files. So you expect here to have out.hex and /dev/mtd6 the same md5s, as well as mtd5 and /dev/mtd5.

If something went wrong, please retry -- try also switching the order of writing: first write mtd/6 first and then mtd5. If it still does not work, do in no circumstance try to fix this with a reboot, as this will it be then! Retry as often you want, the flash will not wear -- at least not before completing 10,000 tries.

If that won't work, please follow this recovery strategy to at least having a change to boot to RedBoot and then manually reconfigure it.  

#Recovery strategy if something went wrong.
#1. KEEP CALM! Panic will not help and tends for actions making things worse
#2. Read the instructions and follow them
#3. If this won't help, do not reboot or power down the La Fonera while you are seeking for help on the net.
# This command will write the RedBoot Config with the mtd command. Unfort. the FIS will be gone afterwards, but you
# have an enabled redboot for recovery. See e.g the OpenWrt-Wiki for details.
mtd -e "RedBoot config" write out.hex "RedBoot config"
# check the md5sum of the /dev/mtd6, it should be the same as for out.hex
# then you can reboot,  but be aware that you have to recover! It will not boot to linux!

(The recovery should is basically the "traditional" method. It is unlikely that you gonna need it.)    

4. Test RedBoot (optional, but recommended)
After the reconfiguration, it is safe to reboot. Please reboot using the command and not by replugging the box. This is to make sure that all filesystem buffers are indeed synced and flushed to the NV-RAM.

After rebooting, you can power down the Fonera, as now you have to prepare your PC for the final test. I assume that you are using Linux, so the commands for reconfiguring are. (You'll need root privileges for that). Don't forget to adapt the lines to your setup. On mine, eth0 is the used network adapter. As the new redboot configuration will listen on the ip address 192.168.1.254, we have to setup the interface to a address in this subnet. For example, you can use

ifconfig eth0 192.168.1.100/24 up

As it listens only 10 seconds, we prepare a small script. (Note, that you won't use root anymore, my dear Windows users!) So in your favorite console, type this command (NB: this is only one line!) to detect the RedBoot and then inject the ^C in time. 

while true; do fping -t 200 192.168.1.254 && break; done; sleep 5;\
echo -e "\x3" | nc -w 1 -vvv 192.168.1.254 9000 ; \
telnet 192.168.1.254 9000

By the way, the sleep seems necessary, as without netcat tries to connect before the port is opened.
Press enter to start the script, and power up the fonera. You'll get:

192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is unreachable
192.168.1.254 is alive
== Executing boot script in 8.260 seconds - enter ^C to abort
^C
RedBoot> RedBoot> Trying 192.168.1.254...
Connected to 192.168.1.254.
Escape character is '^]'. 
 

So, look around, for example help. Please note, that there are commands which actually can cause harm to the La Fonera. Some safe commands are "help", "fconfig -l", "version" or "fis list" to name some. To quit from RedBoot, you can also use a command: "reset". Or you just pull the plug. (PS: If you are not familiar with telnet, you issue the escape character ^] by Ctrl+"]"; followed by enter and then "quit" exits telnet.)

 

[Update February 2014]

The Internet does not forget... Usually. This also true here: The domains stop to exists, there files are not there anymore.

However, they can still be found:

1) http://www.dd-wrt.com/wiki/index.php/La_Fonera_Flashing has two working links, quoting:

    http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma

        Link broken when I tried. Found the file there: http://www.box.net/shared/k19t9kd7no

    http://fonera.info/camicia/out.hex

        Link broken when I tried. Found the file there: http://www.box.net/shared/aj1yb53p12

2) The Way-Back-Machine,  http://archive.org/web/

There, just enter the URLs with the filess you want  (from above, e.g http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma), go in the result to around 2008 and with some luck, download the right file.... However, make sure that you've got the right one and check the mdsums. Repeat/Rinse with a different date until there.

La Fonera | Comments (11) | Trackbacks (0)

Related Articles:

11 Comments | "La Fonera: A better way to enable RedBoot via Telnet / Ethernet (safely) [HowTo]" »

  1. peter : Different results from md5sum

    23/02/2008, at 02:49 [ Reply ]

    First off, thanks for taking the time to write this up. I'll admit to being lazy and it's nice to have a handout from time to time.

    However, I've not been able to get success with this method. Everything works just fine up to the last step- on telnetting in, I never get a RedBoot> prompt- feeding ^C to RedBoot doesn't seem to halt its sequence.

    I noticed the following discrepancy in my output as compared to yours:

    root@OpenWrt:~# md5sum out.hex /dev/mtd/6 mtd5 /dev/mtd/5
    d5a5ee5817da231684c6198801b5cb1f out.hex
    d5a5ee5817da231684c6198801b5cb1f /dev/mtd/6
    52ee83753a9202c317b705750e782691 mtd5
    52ee83753a9202c317b705750e782691 /dev/mtd/5

    So my FIS directory is not the same as yours, but the RedBoot config seems to be the same.

    The thing boots back up find into the FON firmware, but I'm trying to get past that stage.. :)

    Again, thanks for the help.

  2. coldtobi :

    23/02/2008, at 13:35 [ Reply ]

    can you please mail me your FIS Directory to take a look at it. And the output of "dmesg" would help too...
    ( Both of my foneras have "my" layout", so this might need a more indeep look)

  3. Lth : Little mistake...

    24/04/2008, at 12:12 [ Reply ]

    Is:
    for f in *ro; do echo -n "processing $f."; cat $f | gzip /tmp/$f.gz; echo " done"; done

    Should be:
    for f in *ro; do echo -n "processing $f."; cat $f | gzip > /tmp/$f.gz; echo " done"; done

  4. kenjiru : good work

    20/05/2008, at 23:51 [ Reply ]

    Thank you for this piece of documentation. I'm new to La Fonera and RedBoot so it came quite handy.

    Cheers!

  5. xorl : ?

    16/03/2009, at 15:58 [ Reply ]

    "root@OpenWrt:~# cd /tmp
    root@OpenWrt:~# wget http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
    root@OpenWrt:~# wget http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma"

    Why do you wget the same file twice? Also where is vmlinux.bin.l7 supposed to come from?

  6. coldtobi : Re ?

    17/03/2009, at 00:03 [ Reply ]

    > Why do you wget the same file
    twice?

    You're right, one time is enough.

    >Also where is vmlinux.bin.l7 supposed to come from?

    It's the "partition name" of the memory device. Check dmesg for this:

    Searching for RedBoot partition table in spiflash at offset 0x7d0000
    Searching for RedBoot partition table in spiflash at offset 0x7e0000
    5 RedBoot partitions found on MTD device spiflash
    Creating 5 MTD partitions on "spiflash":
    0x00000000-0x00030000 : "RedBoot"
    0x00030000-0x000f0000 : "vmlinux.bin.l7"
    0x000f0000-0x007e0000 : "rootfs"
    0x001f0000-0x007e0000 : "rootfs_data"
    0x007e0000-0x007ef000 : "FIS directory"
    0x007ef000-0x007f0000 : "RedBoot config"

  7. Ben : Re

    09/06/2009, at 22:28 [ Reply ]

    I've a Fonera 2.0 (2202)
    my problem is that I've this partitions :
    "
    root@Fonera:~# cat /proc/mtd
    dev: size erasesize name
    mtd0: 00030000 00010000 "RedBoot"
    mtd1: 00010000 00010000 "loader"
    mtd2: 00620000 00010000 "image"
    mtd3: 0056d17c 00010000 "rootfs"
    mtd4: 001c0000 00010000 "rootfs_data"
    mtd5: 00140000 00010000 "image2"
    mtd6: 0000f000 00010000 "FIS directory"
    mtd7: 00001000 00010000 "RedBoot config"
    mtd8: 00010000 00010000 "boardconfig"
    "

    I am asking how did I do for flashing the vmlinux.bin.l7

  8. coldtobi : Fonera 2.0

    09/06/2009, at 23:42 [ Reply ]

    I do not own a Fonera 2.0, but I am pretty sure: My howto does not apply to the new version. You're likely to break things.

    I'll see if I can find a howto....

  9. Matthijs Kooijman : Kernel patch

    09/08/2010, at 18:47 [ Reply ]

    Your howto is enlightening, it helped me understand what happens better.

    Right now, I'm trying to get a somewhat official howto to get redboot working on the 2.0g (it is enabled on most of them, but there has been one series which got it disabled accidentally).

    Could you perhaps disclose the actual kernel patch you're using to get the mtd writing working? It seems the 2.0g has the same problem with sector sharing that the normal Fonera has, so I can't write the redboot config (and your precompiled kernel is not much use for 2.0g. It also 404s, btw).

  10. andrea : backup

    10/03/2012, at 19:06 [ Reply ]

    hi

    i need to backup only the mtd7 "fullflash" partition of my fonera.

    I have tried this command: cat /dev/mtdblock/7 > /tmp/image.bin

    But it will froze the prompt and doesnt make nothing.

    Can you help me?

1 2  Next»