OK sure, I must say I'm totally addict to RAM-boot and RAM-tools...
I developed my first tools in 1995 for my company: the goal was to backup
from MS-DOS hundreds of computers (286 to 486 running LANMan, NFS, token-ring
or Bull networks) to the new NT servers with a quick, homogen and safe
method.
We used "MS-DOS network client" running on ramdisk from write-locked floppy
disks with submenu to select interface cards to load for network.
Few months later this floppy disk RAM-tool was adapted to massif cloning of
computers in a high school self-service classrooms, without human
intervention.
Some years later we can find on internet nice tools based on ram-boot like
bootdisk.com, portableapps,
DamnSmall, BartPE,
Buldows,and the famous hiren's bootCD.
More and more sophisticated, and still really fan of these products !
FONERAM is just the next try to develop a tool for Fonera(plus).
This version is a major improvement of ram-foneraplus.elf boot-file published
here few months ago
Quid Foneram ?
Not a firmware, not an addon, just a tool
- Directly boot OpenWRT kamikaze 7.06 on your Fonera+ from RAM in less than
one minute, without reflashing.
LAN and WLAN networks are bridged in a single subnet (default 192.168.1.1) ,
and your Fonera+ will act as a classic router if WAN ethernet port is connected
to internet. You can install packages directly from internet, tests your
scripts without risk.
No reflashing, so at next reboot your Fonera+ will start as always: like a
Fonera
- CIFS support to backup raw format partitions, copy files to/from remote computer
- Run, test and play with Webif² from X-Wrt with a little script "instwebif"
- Access to squashfs and JFFS FON partitions ( /rom and /jffs)
- New approach for unlocking a Fonera+: no firmware-version dependant, no
reflashing, and very similar to HTML injection but here we speak about JFFS
injection
- And if you become addict to Foneram , customize yourself your conf by running a script at boot (stored on JFFS partition)
Why Foneram ?
Because it's just possible. Thanks to OpenWRT to implement ramdisk function
in builder.
Because I need a tool to run my fonera and access "offline" the systemfile
(ie make safe backups).
Because I want an open-system, but not to crash or replace it, just to
understand "how it works", add some scripts.
Next model Fonera2.0 (based on same board) will be open, happy to learn FON is
now ready to open their little boxes. 
Read this first !
The goal of Foneram is NOT to reflash your Fonera+. Don't try to reflash
with foneram ! No complaints !
If you plan to install OpenWRT then don't buy a fonera+, considere buying
another router model for the same price.
Consider this a just a tool, no more, and enjoy running OpenWRT for few hours
without reflashing.
There is no reason to brick your foneraplus running foneram, just be prudent
and try to understand what you do.
Warnings !
Not tested on systems running JFFS filesystem-only.
- use on classic fonera
Foneram will run on classic fonera (models 2100/2200) , but was not
developed for. First, no RedBoot enabled, no way to enter Foneram.... This is
not a problem on 2200 model .
Not working on classic fonera: ethernet port ! Not a problem
of config, but ethernet driver is not the same.
Mounting FON filesystem (/rom /jffs) is working with scripts described here,
but some existing files to edit may appear corrupted.
JFFS2_BBC compression is implemented on classic fonera only and not in FONERAM.
Don't edit these files in case of trouble, but you can add, delete, or rename
files without risk.
To unlock a 2200, just mount your JFFS, and imagine the nice one-line script to
invent
- Running Foneram with alternative firmware flashed.
No warranty accessing the JFFS. Partition "config" is taken from the last
available block of JFFS while running FON firmware.
Size of JFFS displayed may appear shorten by 64kB ( 1 block) running
foneram.
Sources
95% of tasks performed by foneram are not new ! Main source to compile is
kamikaze 7.06 downloaded from svn.openwrt.org.
Ethernet driver for ar2313 is coming from FON foneraplus source. Check this nice page on LeFinnois website for more infos
Scripts for blinking LEDS and the Redboot-partition-scan patch (to display
"config" partition) were also extracted from FON sources.
Lot of infos gathered through meraki and OpenWRT forums.
Thanks ...
First a big thanks to OpenWRT team for this nice open-source product!
Also to foneros, FON and Martin V. to make this hardware so popular..
And special thanks to all guys testing foneram since last weeks, especially
skynetbbs and Davide Lenzarini who helped me for the last corrections of this
doc..
How to run
- Configure your computer: IP address 192.168.1.254
- Download and extract file foneram-plus.elf from here (update 12-04-2008) to your
TFTP directory server.
- Access RedBoot console (default is 192.168.1.1 port 9000)
RedBoot> load foneram-plus.elf
Using default protocol (TFTP)
Entry point 0x80271000, address range 0x80041000-0x80xxxxxx
RedBoot> go
( serial access reports system boot)
- Wait 1 minute leds POWER and WLAN are alternatively
blinking orange.
Wifi network is WEP encrypted. WEP-key is the serial number of your
Fonera+
Root password is the serial number of your Fonera+
- Then try to connect Telnet/SSH to 192.168.1.1 on LAN port or WLAN
BusyBox v1.4.2 (2008-02-06 10:52:52 CET) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
______
/\ ___\
\ \ \__/ __ ___ __ _ __ __ ______
\ \ _\/ __`\ /' _ `\ /'__`\/\`'__\/'__`\ /'__ __`\
\ \ \/\ \_\ \/\ \/\ \/\ __/\ \ \//\ \_\.\_\ \ \ \ \ \
\ \_\ \____/\ \_\ \_\ \____\\ \_\\ \__/.\_\\ \ \ \ \ \
\/_/\/___/ \/_/\/_/\/____/ \/_/ \/__/\/_/ \_\ \_\ \_\
---------------------------------------------
Based on OpenWrt - http://www.openwrt.org
Kamikaze 7.06 - kernel 2.6.19.2
Ram-version for la Fonera+ - 01/2008
---------------------------------------------------
root@LamaBleu:/#
If WAN port is connected to internet through DHCP router, check connectivity
with command "date" for example.
If you can't connect to internet, try to check if default route is OK.
FONERAM tour...
RedBoot partitions vs MTD spiflash
Example shown here is with a fonera+ running official FON firmware
Partitions list from RedBoot console:
Name FLASH addr Mem addr Length Entry point
RedBoot 0xA8000000 0xA8000000 0x00030000 0x00000000
loader 0xA8030000 0x80100000 0x00010000 0x80100000
image 0xA8040000 0x80040400 0x00230004 0x80040400
image2 0xA8660000 0xA8660000 0x00140000 0x80040400
FIS directory 0xA87E0000 0xA87E0000 0x0000F000 0x00000000
RedBoot config 0xA87EF000 0xA87EF000 0x00001000 0x00000000
and from shell:
root@LamaBleu:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00030000 00010000 "RedBoot"
mtd1: 00010000 00010000 "loader"
mtd2: 00620000 00010000 "image"
mtd3: 0056afc0 00010000 "rootfs"
mtd4: 003f0000 00010000 "rootfs_data"
mtd5: 00010000 00010000 "config"
mtd6: 00140000 00010000 "image2"
mtd7: 0000f000 00010000 "FIS directory"
mtd8: 00001000 00010000 "RedBoot config"
mtd9: 00010000 00010000 "board_config"
Ohhh ! Not the same result
At boot, spiflash utility will try to find (create dynamic) JFFS partition
located at first available block (at the end of squashfs part for "image"
partition) on flash.
JFFS "rootfs_data" and "config" partitions are ignored by RedBoot as in classic
fonera.
A 64k-size (1 block) partition "config" is also created in last available
block on flash memory.
This little partition is used by FON to store your config in a .gz file
while upgrading firmware.
MTD image: mtd2 is 12bytes header + kernel + squashfs +
rootfs_data (JFFS) + config
MTD rootfs: mtd3 is squashfs + rootfs_data
MTD rootfs_data: mtd4 is rootfs_data (JFFS)
Note spiflash "image" partition, and RedBoot "image" partition (FON
firmware) are not equivalent. Size is really different...
RedBoot image partition is a (12-byte header + kernel +
squashfs) only.
Access FON datas :
root@LamaBleu:/# mtd-mount
*** mount /dev/mtdblock3 on /rom (read-only)
*** mount /dev/mtdblock4 on /jffs
Then take a look at /jffs and /rom Welcome to FON filesystem
Warning on classic Fonera: use of this script will work also but
partition numbers are not the same. Use at own risk, no
warranty
Umount :
root@LamaBleu:/# mtd-umount
*** umount /jffs
*** umount /rom
root@LamaBleu:/#
Use at own risk, if you try to manually mount partitions of wrong type you
will corrupt "image" partition !
Only use the script OK ??
Install packages from internet
First run "ipkg update" command
root@LamaBleu:/sbin# ipkg update Downloading http://downloads.openwrt.org/kamikaze/7.06/atheros-2.6/packages/Pa ckages Updated list of available packages in /usr/lib/ipkg/lists/OpenWrt Downloading http://downloads.x-wrt.org/xwrt/kamikaze/7.06/atheros-2.6/packages/ Packages Updated list of available packages in /usr/lib/ipkg/lists/X-Wrt Done.
Install a package (will be installed on ram only, FON system is left untouched, so this is valid until next reboot only)
root@LamaBleu:~# ipkgsh install tcpdump
Downloading http://downloads.openwrt.org/kamikaze/7.06/atheros-2.6/pac
kages/./libpcap_0.9.4-1_mips.ipk ...
Connecting to downloads.openwrt.org [195.56.146.238:80]
libpcap_0.9.4-1_mips 100% |*****************************| 68956 --:--:-- ETA
Done.
Unpacking libpcap...Done.
Configuring libpcap...Done.
Downloading http://downloads.openwrt.org/kamikaze/7.06/atheros-2.6/pack
ages/./tcpdump_3.9.4-1_mips.ipk ...
Connecting to downloads.openwrt.org [195.56.146.238:80]
tcpdump_3.9.4-1_mips 100% |*****************************| 293 KB 00:00:00 ETA
Done.
Unpacking tcpdump...Done.
Configuring tcpdump...Done.
Unlock your FON Fonera+
root@LamaBleu:/# 2201-unlock
mount jffs on /jffs
create directories on jffs...
serial port access ...
copying dropbear files (wait 2 mins)...
dropbear auto-launch ...
*** at next reboot, dropbear needs to generate keys,
wait few minutes before connecting via dropbear ***
OK, done !
root@LamaBleu:/#
This script is running on all known firmware versions prior to 28 march
2008, but on foneraplus only
By this method we don't need to reflash original firmware or erase existing
JFFS. All needed files are injected to JFFS.
At next FON reboot, wait few minutes before trying to connect to
dropbear.
Your previous parameters are still intacts.
Restore default factory settings.
Exactly same method as classic fonera. All personal parameters will be erased
and the foneraplus re-locked
From FONERAM, mount the jffs, then erase the contents.
Reboot and reconfigure your "new" Foneraplus.
root@LamaBleu:/# mtd-mount
*** mount /dev/mtdblock3 on /rom (read-only)
*** mount /dev/mtdblock4 on /jffs
root@LamaBleu:/# rm -Rf /jffs/*
CIFS remote shares, backup/restore fonera datas
CIFS: access to a remote computer
Take a look at /sbin/cifs simple script and adapt !
mount -t cifs //$1/foneraplus /mnt -o user=foneraplus,passwd=foneraplus
losetup /dev/loop0 /mnt/swapfonera
swapon /dev/loop0
To use the script, create on your remote computer a new account user:
foneraplus with same password.
Create and make share named "foneraplus" on your comuter.
Then run "cifs 192.168.1.254" to mount remote share "foneraplus" on /mnt
Adapt sharename and account properties
If you plan to use a swapfile to extend your memory, create your swapfile ( 8MB here):
- mount the CIFS share - run commands:
dd if=/dev/zero bs=1024 count=8192 of=/mnt/swapfonera
losetup /dev/loop0 /mnt/swapfonera
mkswap /dev/loop0
swapon /dev/loop0
Backup/restore datas
Easy, and quick, I use CIFS share to preserve memory usage in /tmp for big
files. You can also use SCP transfers to-from /tmp if you don't plan to use
CIFS network filesystem.
Backup
- mount a CIFS ressource in /mnt as described in previous section
- Raw backup for your JFFS partition as raw format (partition dump):
dd if=/dev/mtdblock4 of=/mnt/rootfs_data.bin
(this will create a 0x003f0000 file size : only your JFFS data)
dd if=/dev/mtdblock2 of=/mnt/image.bin
(this will create a 0x00620000 file size)
- Backup your JFFS partition as tgz format:
root@LamaBleu:~# tar -czv -f /mnt/jffs_fon.tgz /jffs/
tar: removing leading '/' from member names
jffs/
jffs/bin/
jffs/bin/nul
jffs/bin/mail
jffs/bin/mount_nas
jffs/bin/thinclient
.........
root@LamaBleu:~# ls -l /mnt/*.tgz
-rw-r--r-- 1 root root 1395090 Mar 24 08:47 /mnt/jffs_fon.tgz
Remark : backuping only /etc/config directory is a quick and good solution to
save your FON parameters.
Restore from previous backup
Use at own risk, be sure to understand first what you will do running
flashing commands.
Reading the post "How to unbrick/revive a Foneraplus" may help you to have a
better look of reflashing.
Before reflashing partitions, take care to check file size for example, or
hex-comparing binaries (present on flash, and to reflash)
Examples here are shown using CIFS to restore from a NAS or remote
computer.
- RAW format : You can reflash from RedBoot these partitions previously saved as raw format
- image2, loader partitions
in brief: "load -r -b 0x80100000 image2.bin" then "fis create image2", same for
loader partition
note that there is no reason to reflash these partitions
unless your fonera is bricked
- reflash FON firmware + JFFS:
These commands are very similar to those described for unlocking/unbricking
Fonera+ on wiki.fonboard.nl
- From RedBoot:
load -r -b 0x80100000 image.bin
fis write -b 0x80100000 -f 0xa8040000 -l 0x00610000
last block (offset 0x00610000 - size 64kb) is "config" partition, and
not used here to restore
- Restoring raw dump from foneram shell:
This is just "reflashing from shell, not from RedBoot" Be sure /jffs is not
mounted
Mount CIFS share to access files raw-backup files
mtd write /mnt/image.bin image
Flashing time is long, be patient !
reflash JFFS only from a raw backup:
Reflashing JFFS may corrupt your FON configuration ! Be sure to have
a good reason to do it, at own risk !
This will erase all datas on JFFS and restore a previous backup. Actual
settings will be lost make a bakup first!
If reflashing from shell be sure JFFS (/dev/mtdblock4) is not mounted on
filesystem.
Commands below are valid for firmware 1.1.x.x (where data size
for firmware is 22* 64k-blocks)and subject to change ( actual file size for
mtd4: 003f0000)
For JFFS restore prefer to restore from a .tgz file (previous backup) or full
reflash ( finrmware + JFFS)
From Redboot
load -r -b 0x80100000 rootfs_data.bin fis write -b 0x80320000 -f 0xa8260000 -l 0x003f0000
From shell
mtd write /mnt/rootfs_data.bin image
- restore JFFS only from tgz backup:
Prefer to use this method, if you're only interested in restoring your JFFS
personal datas (you don't need to reflash FON image partition at each time
)
Using CIFS (remote share mounted on /mnt)
First erase your JFFS partition (previous data are erased), then restore
datas
rm -rf /jffs/
tar -xzv -f /mnt/jffs_fon.tgz -C /
If you don't want to use CIFS share access, SCP-transfer your .tgz backup on
/tmp and launch the restore command.
Customize your FONERAM
Auto-launch of customizable script at foneram-boot
At boot, FONERAM will try to launch a script "script.sh" in
/jffs/foneram
How to save the script.sh the first time
:
use script "2201_mount" using foneram to mount (FON-)JFFS : content is
available in /jffs
or while running FON on unlocked foneraplus JFFS is also avalaible in
/jffs
Then create a directory /jffs/foneram
Create a new script "script.sh" in /jffs/foneram directory, and insert commands
for your own customization. Make it executable (chmod +x script.sh)
- Example: insert this lines to change subnet for bridge (LAN port and WiFi) from 192.168.1.0 to 192.168.22.0 at next foneram-boot
uci set network.lan.ipaddr=192.168.22.1
uci commit
- Example: make foneram WLAN-client of another master-AP for internet access, and setup ethernet interfaces LAN and WAN as LAN port.
uci set network.lan.ifname='eth0.0 eth0.1'
uci set network.wan.ifname=ath0
uci set wireless.wifi0.channel=0
uci set wireless.cfg2.network=wan
uci set wireless.cfg2.mode=sta
uci set wireless.cfg2.ssid=master-ssid
uci set wireless.cfg2.encryption=wep
uci set wireless.cfg2.key=1
uci set wireless.cfg2.key1=01234567890123456789012345
uci commit
killall udhcpc
/etc/init.d/network reload
Semi-automatic startup for FONERAM
Lazy and tired accessing RedBoot console ? Want to launch Foneram without
intervention ?
OK you can ask your fonera+ to download the foneram-plus.elf file at boot
through TFTP directly from your computer.
Just launch your TFTP server with foneram-plus.elf file stored in the root
TFTP server directory.
If you're fonera+ can't locate the TFTP server on network (not launched), then
the FON partition will be loaded as usual.
So modify your boot script for RedBoot, at own risk, be prudent while
re-typing the init script. This is inspired from Meraki boot.
If you want to boot FON partition (TFTP server not launched), the timeout is
about 1 minute, maybe more, be patient.
RedBoot> fconfig boot_script_data
boot_script_data:
.. fis load loader
.. go 0x80100000
Enter script, terminate with empty line
>> load foneram-plus.elf
>> go
>> fis load loader
>> go 0x80100000
>>
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .
RedBoot>
