LaFonera Software Flashing Ubuntu

From DD-WRT Wiki

Jump to: navigation, search

I have attempted to take large portions of the LaFonera Software Flashing guide and rewrite it specifically for Ubuntu. The main article lacked a lot of information which would of been helpful and if I hadn't of had some networking expierence, I would of pulled a lot of my hair out. I'm not very good at editing wiki pages, so please, edit the formatting to make it more wiki friendly, I also copied/pasted a lot of the LaFonera_Software_Flashing article into sections as I didn't feel like rewriting it. This article was written from the viewpoint of not wanting to connect the fon to the internet (as my fon was 0.7.0 r4 and had never been hooked to the internet) Dewdude 00:49, 7 July 2009 (CEST)

Contents

[edit] Requirements

You will need the following to make use of this article:

  • Ubuntu (tested with 9.04, but will likely work for others)
  • SSH access on your FON
  • Firmware Files
  • webfs for quick sharing of files over HTTP
  • tftpd-hpa for tftp purposes

[edit] Stuff to do

[edit] Enable the built-in SSH server

Enable the built-in SSH server on the LaFonera

  • For a LaFonera with firmware 0.7.1 r1 or before: over wireless or over Ethernet (easier)
  • For a LaFonera with firmware 0.7.1 r2 use: http://stefans.datenbruch.de/lafonera/#kolofonium)
    • Easy deployment of the Kolofinum hack: Change the name server (DNS) of your La Fonera to 88.198.165.155, reboot and connect it to the Internet via Ethernet.
      A fake DNS server at that IP applies the hack to your router for you, and you can now connect via SSH (until the next reboot). No need to download HTML hacks and manual edi files. This should work with other firmwares, too. When done, change the name server according back to your usual ISP or LAN setup.
      • NOTE: If you reset your too early dns and allow the fonera to "phone home" it will likely run a firmware update that will bring you up to 0.7.2 r3. You don't want this to happen so it is best if you keep the dns setup until you have completed flashing
    • Alternative methosd: this works on the newest firmware that has been hard-coded on the new chips
      • Hold reset button for 30 seconds
      • Remove the power connector while still holding reset.
      • Replace power connector and continue holding reset button until "wifi" lights up and goes away again (a good 2-3 minutes of holding it).
      • Let go and wait for "wifi" to come back (2-3 minutes).
      • Now you may use the "step1.html" and "step2.html" method to turn SSH on as you would with the normal "r1" LaFonera. It will still continue to say "r2" on the LaFonera status page whilst you enjoy your SSH connection.


[edit] Download Firmware Files

You'll need to download the following files:

    1. http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
    2. http://fonera.info/camicia/out.hex

[edit] Prepare Ubuntu

In order to flash the fon, we need ways of getting the data in to the unit. Since we don't want to connect it to the internet and risk it upgrading itself, we'll need to install an http server for the first task and a tftp server for the second part. (Note: TFTP is NOT the same as FTP).

Run the following command on your Ubuntu machine

sudo apt-get install tftpd-hpa webfs

The default configuration will work fine. Files are to go in /var/www and the server is running on port 8000. To start webfsd, run the following command

sudo /etc/init.d/webfsd start

tfpd-hpa's configuration file is at /etc/default/tftpd-hpa and needs some slight modification to look like this:

#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /var/lib/tftpboot"

The only real change is setting RUN_DAEMON to yes rather than no. The options like shows where the files are going to be stored, in this case, the default of /var/lib/tftpboot. In order to make sure we don't have any problems with tftp acessing this files. If the directory doesn't exist, then create it with sudo mkdir /var/lib/tftpboot, then, run the following commands

sudo chown nobody.nogroup /var/lib/tftpboot
sudo chmod 777 /var/lib/tftpboot

This will ensure there are no premissions issues. Once you have your directory squared away, you should be able to start tftpd-hpa with the following command

sudo /etc/init.d/tftpd-hpa start

Now, once the daemons are started, you'll want to make sure you put the openwrt...lzma and the out.hex in to /var/www (or wherever you told webfsd to pull files from) and the dd-wrt linux.bin file in /var/lib/tftpboot. Once you've done all that, guess what, you've configured everything you need to put the files on the Fon and can proceed with flashing.

[edit] Connecting to the Fon

There are two ways of connecting to your fon at this point. You can either connect to the encrypted MyPlace hotspot, using the unit's S/N as a wpa key, or you can plug a network cable in to your computer and ethernet port of the Fon. As I mentioned, the port is auto-sensing so there's no need for a crossover cable or any of that junk.

When you connect via WiFi, the Fon will assign your WLAN card an IP as normal. The default IP for the Fon is 192.168.10.1. The root password is "admin". The entire command would look something like this:

user@host:/current/directory$ ssh root@192.168.10.1

you're then prompted for the password. Once you're in, you'll see the Fon page and will be back at a command prompt.

If you connect via ethernet, DHCP is not running on the ethernet port, likewise, the ethernet port is expecting to get it's IP from your ISP's DHCP. The port will go into an auto-local mode and assign itself an IP of 169.254.255.1 with a subnet of 255.255.0.0. In the Network Center in Gnome, if you right click and select Edit Connections, one of the options under the ath0 configuration on the IPv4 settings tap is "Local-Link Only". You can select this and your Ubuntu machine and Fon will be able to communicate.

If you try to connect using ethernet and find you can't get to the router using the IP I specificed, it's possible it's on another IP. Connect to the router via MyPlace hotspot and connect to SSH over it, once you're connected, run ifconfig. you should get a lot of options, but you're looking for eth0, you should see a 169. address. Once you have that address, you can disconnect from the wifi and try the wired port again. Getting the wired portion to work now IS NOT critical, for ease of things you can just use the wifi for now, but a wired connection WILL BE required in a bit.

Once you're connected to the FON's SSH, one of the first things you need to do is run the following command:

mv /etc/init.d/dropbear /etc/init.d/S50dropbear

This makes sure that SSH will be enabled after we reboot later on.

[edit] Additional Preperation

The first thing we need to do is load a hacked FON kernal so we can write on the mtd partition with Redboot. When you're connected to the FON's SSH, you'll need to determine what the IP of your computer is. You can find out by right-clicking on the network icon at the top of the screen and selecting "Connection Properties", there you'll be given the information about any active connections. Select the tab for whatever connection you're using to talk to the Fon. Go back to your SSH session and enter the following commands:

cd /tmp
wget http://<ubuntu ip>:8000/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
reboot

At this point the Fon will reboot and after a few minutes, you should be able to connect to it over SSH again. Once you are logged back in to SSH on the Fon (the IP's haven't changed), you need to run these commands:

cd /tmp
wget http://<ubuntu ip>:8000/out.hex
mtd -e "RedBoot config" write out.hex "RedBoot config"
reboot

Remember: EVERYTHING is case-sensitive...this is *nix, not *doze. If you get errors, DOUBLE CHECK YOUR CASE! It doesn't matter where in the command the case is wrong, if it's wrong, it's wrong.

After you run these commands, you will NOT be able to SSH in to your Fon anymore, nor will you be able to communicate with it via WiFi. We have wiped it's FIS directory, so the only connectivity we have is through RedBoot.

[edit] RedBoot

At this point, if you've been communicating with your FON on one network connection and using the other to maintain internet, you'll need to sever your internet connection. In order for this to work, you cannot have any other external connections.

Right-click on your network-icon and select edit connections and bring up the edit box for your wired connection. What you'll want to do is select eth0 and after hitting the edit button, hit the IPv4 settings tab. Where it says either Auto (DHCP) or Local-Link, you'll want to change it to "Manual". Just for sake of ease, set your IP to 192.168.1.100 with a subnet of 255.255.255.0; you do not need to worry about gateway or DNS settings, they do not apply here.

Now, the thing to know about RedBoot is that you've got 10 seconds after the router boots to connect to it before the router basically goes dead. So, you're not going to get it as soon as you issue the reboot command in the previous step. Instead, just set your network settings, plug in the network cable and unplug power from the router. What I suggest you do now is get your telnet connect command ready. RedBoot uses an IP of 192.168.1.254 and a telnet port of 9000, the command looks like this:

telnet 192.168.1.254 9000

What I'll do is plug the router up, wait a second, then hit enter. If I get an error, I'll quickly hit up to repeat the command and enter again. Sometimes RedBoot won't display anything when you first connect (it didn't for me), but the key was after I issued the connect command, it did not error, it just sat there acting like it was trying to connect. After I pressed enter I was given the Connected message and a redboot prompt, along with a couple of error messages:

Connected to 192.168.1.254.
Escape character is '^]'.
== Executing boot script in 5.650 seconds - enter ^C to abort
== Executing boot script in 5.650 seconds - enter ^C to abort
RedBoot> No image 'vmlinux.bin.l7' found
RedBoot> Can't execute Linux - invalid entry address

This is basically what we want to see. It shows we're in RedBoot and that since we did things right, it can't execute Linux.

The first thing we need to do is configure the local address for RedBoot to use along with the "remote" address that points to our ubuntu box running tftpd-hpa. When I ran mine, I set the IP for eth0 to 192.168.1.66, so my command looked like this:

RedBoot> ip_address -l 192.168.1.254/24 -h 192.168.1.66

If you couldn't tell, -l defines the "local" address and -h defines the remote IP, which for sake of discussion is the IP of our Ubuntu box. We'll need to format the flash image system, so let's go ahead and do that

RedBoot> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .

This will likely take a few minutes, so be patient. When you're greeted with antoher RedBoot> prompt, you're ready to continue to the next portion, loading the dd-wrt image in to the unit. Hopefully if you followed the directions earleir about tftpd-hpa, this should go off without a hitch. It took me a little while to get it working which is why I was able to compound it in to two simple steps....set as daemon and start 'er up.

RedBoot> load -r -b 0x80041000 linux.bin
Using default protocol (TFTP)
Raw file loaded 0x80041000-0x80662fff, assumed entry at 0x80041000

Now, if you thought the formatting took a while, well, guess what. This next step is about to take even longer...up to an hour in some cases. We're not quite done yet, but what we're going to do is write the new firmware in to memory.

RedBoot> fis create linux

It will sit and look like it's not doing anything...but it is. On my system, the connection did not auto-disconnect due to idle so it's 99% likely yours won't either. You don't need to sit there and watch it, you can get up and go do something else while waiting. When it's done, you SHOULD see this:

... Erase from 0xa8030000-0xa86a1000: ........................................................................................................
... Program from 0x80041000-0x806b2000 at 0xa8030000: ........................................................................................................
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .

We're not quite done yet, we still need to set up the boot script. Here is a display of the commands you'll need to run, along with how you'll need to answer the prompts.

RedBoot> fconfig
Run script at boot: true
Boot script:
.. fis load -l vmlinux.bin.l7
.. exec
Enter script, terminate with empty line

If you copy/paste these commands, you do not need to paste >> with it.

>> fis load -l linux
>> exec
>>
Boot script timeout (1000ms resolution): 10
Use BOOTP for network configuration: false
Gateway IP address:
Local IP address: 192.168.1.254
Local IP address mask: 255.255.255.0
Default server IP address: <blank>
Console baud rate: 9600
GDB connection port: 9000
Force console for special debug messages: false
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xa87e0000-0xa87f0000: .
... Program from 0x80ff0000-0x81000000 at 0xa87e0000: .

That's it, you're done flasing your Fonera with dd-wrt. All you have to do now is reset the unit.

RedBoot>reset

The unit will reset and will reboot in to dd-wrt.

[edit] Clearing Settings

If you're like me, you're gonna screw the settings up. It is possible to restore dd-wrt to "factory" settings. One method involves holding down the reset button after the unit has had enough time to boot up. I tried that, and it didn't work...my unit was still stuck in Wireless Bridge mode. However, I found this method worked for me on the most recent preSP2 build:

    1. Unplug the Fonera router from the power.
    2. Press the reset button on the bottom of the unit
    3. While holding the reset button, apply power, wait 5 seconds, let off the reset button

This merely did a factory-reset of dd-wrt rather than clearning the thing entirely. Your milage may vary, each unit is different.