One reason the iLiad is easy to brick is that the setup requires the GUI to be functioning before any user interaction can take place. For most of my projects with embedded systems I always enable the ethernet and sshd long before we try to start up the gui so that we have a way in if things go wrong.

To that end, attached is a tar file that you can unpack in the root directory that will enable the ethernet with a static IP (10.0.0.200) and start sshd so that you can login as root over the network. The root password is set to 'rootme', in keeping with the Familiar distribution, you'll need to change it once you log in.

The network comes up about 1/2 the way into the boot process, then sshd is enabled about 3/4 of the way, as measured by the little bar graph on startup. There does not seem to be any increase in the time to boot. I do not know how much power the ethernet draws, but I know it is much less than the wireless. There may still be some reduction in battery life, but you could easily add an shell hack entry to turn it off. A simple 'ifdown eth0' will also unload the smc91x module.

One important note -- the iLiad does not have bzip2, so you will have to uncompress it on your Linux box before installation. One way to do that is to combine the decompress with the unpacking:
bzcat unbrickable.tar.bz2 | ssh root@ereader tar -C / -xvf -
The file manifest in the tar file is:
-rw-r--r-- root/root 319 2007-04-01 11:28:31 ./etc/network/interfaces
drwxr-xr-x root/root 0 2007-04-01 11:36:55 ./etc/dropbear/
-rwxr-xr-x root/root 427 2007-04-01 11:36:55 ./etc/dropbear/dropbear_dsa_host_key
-rwxr-xr-x root/root 460 2007-04-01 11:36:55 ./etc/dropbear/dropbear_dss_host_key
-rwxr-xr-x root/root 424 2007-04-01 11:39:13 ./etc/init.d/dropbear
lrwxrwxrwx root/root 0 2007-04-01 11:40:54 ./etc/rc5.d/S98dropbear -> ../init.d/dropbear
-rwxr-xr-x root/root 214442 2007-04-01 11:37:28 ./usr/bin/dropbear
-rw-r--r-- root/root 732 2007-04-01 11:43:49 ./etc/passwd


Adam B. Edit:
Post Updated with most recent version of Unbrickable package (unbrickable.tar.bz2) with dropbear 0.49 with scp. See this post (http://www.mobileread.com/forums/showpost.php?p=67826&postcount=10)

Also Updated with ipkg installer package w/ dhcp. See this post (http://www.mobileread.com/forums/showpost.php?p=68827&postcount=15)

For most of my projects with embedded systems I always enable the ethernet and sshd long before we try to start up the gui so that we have a way in if things go wrong.

To that end, attached is a tar file that you can unpack in the root directory that will enable the ethernet with a static IP (10.0.0.200) and start sshd

Ok, so now nothing stop us from substituting the GUI :-b

this is a nice package, but I fail to see it as "unbrickable". Recently a script was shown doing a cd to a directory that didn't exist ( that failed ), followed by an rm -rf * . (which had / as the cwd). For that kind of mistakes, as well as some fs / master config files being overwritten, the irex-promised unbricking is needed.

this is a nice package, but I fail to see it as "unbrickable". Recently a script was shown doing a cd to a directory that didn't exist ( that failed ), followed by an rm -rf * . (which had / as the cwd). For that kind of mistakes, as well as some fs / master config files being overwritten, the irex-promised unbricking is needed.
You're right that it is still possible to hose the system to the point that it requires a return trip back to Eindhoven, but the chance of a bad /mnt/settings preventing the boot from completing is far lower. Running 'rm -rf /' on any Linux system is a bad idea and will set you back on any machine, especially if it takes out your /boot and /bin directories. Even Apple has messed up shell expansion in install scripts before -- they did a "rm -rf /Volumes/$DRIVE, where $DRIVE was a drive name selected from the gui. If the drive had a leading space in the name it would execute 'rm -rf /Volumes/', effectively wiping ALL the drives currently mounted.

But, from my perspective, baring any serious screwups this patch makes my unit far less likely to need to visit its home. I can rebuild my kdrive-Xfbdev to include the evdev patches without worry that I won't be able to get to my device if the X server doesn't start.

As for reflashing at home, the xscale PXA255 CPU has three serial ports, one of which almost always has a boot loader console in most implementations. I see in the dmesg output that the three of them are detected and initialized, but haven't pulled my device apart to find the ports are level shifted to RS232 or are still 3V TTL.

How about setting important files immutable using chattr to prevent even "rm -rf" accidents?

Great work. While this wouldn't help me in my situation, it would be great for most of the possible screwups that could happen. :thumbsup:

you can´t

I've just tested the tar file after the upgrade to 2.9.5 and it works fine. Copy it to /media/iLiad after mounting it, then using mrxvt run:

tar -C / -jxvf /mnt/free/unbrickable.tar.bz2

Reboot and enjoy the ability to ssh into 10.0.0.200 as root with the password rootme.

As an added note, after installing this, I installed the dropbear ipkg that Mathijis posted a while back. This allows me to scp into the iLiad as well.

I also changed my /etc/network/interfaces for DHCP.


auto eth0
iface eth0 inet dhcp
pre-up modprobe smc91x
post-down rmmod smc91x


My DHCP server gives my iLiad the same IP every time, so I don't have to worry about connecting to a different address. Makes my life easy when working on and testing iLiad apps.

Thanks for the package hudson. :thumbsup:

As an added note, after installing this, I installed the dropbear ipkg that Mathijis posted a while back. This allows me to scp into the iLiad as well.

I had meant to post this update that also includes the scp binary, as well as an upgraded dropbear 0.49 instead of the 0.47 version. scp is really the way to move files to the unit since, unlike USB, it doesn't lock you out of the GUI.

I got my shell access the other day and this was one of the first things I installed. Excellent work, and elegant. Thank you for providing it! It's allowed me to test xserver stuff I would never have dared to try otherwise.

I'm looking forward to using scp, since currently I move files by shuttling the CF card back and forth from desktop to iLiad. I feel so old-fashioned!

How about setting important files immutable using chattr to prevent even "rm -rf" accidents?

Alex, one of the things that makes the SHELL hack so dangerous is that it executes as the super user root. Since iRex didn't implement ACL's there is nothing you can do to protect critical system files from a root script.

Note: one of the nice/bad things about the Sony Reader is that the critical system files are in a read only filesystem. This kind of accident can't occur on the Sony, but you also have a bit more work to do 3rd party mods on the Sony. :-)

I also wonder if the iRex re-flash can recover from this kind of accident.

To that end, attached is a tar file that you can unpack in the root directory that will enable the ethernet with a static IP (10.0.0.200) and start sshd so that you can login as root over the network.

A nice packaging of the work Design256 described here last year after the Arrivero hack broke the iLiad wide open.

Yes, it does increase power draw if left up. I personally have a .sh script to do the ifdown you describe (mine also kills the dropbear as well.)

One caution for anyone planning to use this package. Design256's method didn't leave your iLiad vulnerable to attack, this package does.

If you bring up wireless your dropbear is reachable from the internet. Someone scanning the public access points (and boy do people spend alot of time doing that, its amazing!) could enter root/rootme and you're pwned.

To protect yourself you should leave out the /etc/passwd from the TAR and just use the passwd command to set your own private root password. To enhance your security one more notch generate your own keys for these files:


-rwxr-xr-x root/root 427 2007-04-01 08:36:55 ./etc/dropbear/dropbear_dsa_host_key
-rwxr-xr-x root/root 460 2007-04-01 08:36:55 ./etc/dropbear/dropbear_dss_host_key


And then setup this file with a pass phrase on the key itself:


-rwx------ 1 root root 899 Apr 27 09:09 /home/root/.ssh/authorized_keys


That will keep silly accidents from happening. Here in Seattle we have free Wifi on some of the buses. It would really suck to forget about the open dropbear and go wireless for a little dillo/CNN action after hearing some incredible rumor from another passenger.

Other unbrickable iLiad possibilities proposed in the past.

The iLiad has a getty running on the PXA-255's built in UART. This may in fact be how iRex fixes some of the bricked iLiad's returned to them. I've asked them several times to make a cable available for developers. Heck I' offered to setup an account with one of the short run production outfits to make them easily available in the US if they'd send me a PDF of the cable. Maybe your voice will be the straw that breaks the camel's back.

The iLiad also implements the JTAG built into the PXA-255. I described to iRex how an inexpensive USB cable could be produced that would enable un-bricking even a totally zapped FLASH (no root fs, no kernel). I was willing to design the cable and have it setup for short run production at one of the places mentioned above, all that was needed was cooperation from iRex. Not only did I get a no, I got a HELL NO.

The iLiad also implements the JTAG built into the PXA-255. I described to iRex how an inexpensive USB cable could be produced that would enable un-bricking even a totally zapped FLASH (no root fs, no kernel). I was willing to design the cable and have it setup for short run production at one of the places mentioned above, all that was needed was cooperation from iRex. Not only did I get a no, I got a HELL NO.

This sounds quite interesting. Would you mind explaining here how this cable would allow you to do the unbricking/reflashing?

Regarding access to the pxa-255 serial console...so do you think this is just an issue of getting a map of the pinouts used by that funky (what is it, 20 pin?) connector that attaches the travel hub or would some other hardware hack be needed to get access to the UART pins?

I've gone ahead and set it up into an installable ipkg file. Simply unzip, copy and run.

I've set it up with dhcp (more useful for the average user), so you'll need to download mrxvt and run `ifconfig` to find your IP address. You can change this in /etc/network/interfaces.

This will be the 1st thing to deal with after my iLiad's return from a journey to Eindhoven, NL.
After installing it I can hack /home/root/start.sh again. :p

Thank you! It works great. :)

Now, I got a question. I want to disable the network connection after the boot process finished to save battery life. But I don't know how can I re-enable the network connection.

I tried 'connectionMgr --background --stay-connected' but the lamp of the LAN port just blinked once and nothing happened. The command 'ifconfig' says no network connection established. What should I do?

I want to disable the network connection after the boot process finished to save battery life. But I don't know how can I re-enable the network connection.

I just run 'ifup eth0'. If you are using my /etc/network/interfaces file it will automatically load the smc91x kernel module and configure the interface. Likewise, 'ifdown eth0' will unload the module to save on battery.

I just run 'ifup eth0'. If you are using my /etc/network/interfaces file it will automatically load the smc91x kernel module and configure the interface. Likewise, 'ifdown eth0' will unload the module to save on battery.

It works great and even faster than 'connectionMgr' command. Thank you so much!

By the way, 'ifdown' command does not work at once. The SSH connection is closed after that command, but the lamp on the LAN port is still on. The lamp turns off when I execute the same command once again. So I made a semi-wise script:

ifdown eth0
sleep 1
ifdown eth0

Just in case someone overlooked this: Matthijs made a very useful suggestion to add an extra symlink from /etc/rc5.d/S99-unbrick to an executable /mnt/cf/unbrickable.sh which might be used as a second rescue device if something went wrong.

For the lazy ones I have attached a script which creates this link. I have tested it and it works for me, also in the case if the target does not exist.

Yamp! I have ssh access to my little iLiad during booting process. :happy2:
In Windows World I use PuTTY to log in.

I have set a symlink from /etc/rc5.d/S99-unbrick to a /mnt/cf/unbrickable.sh, but script doesn't run during booting. I don't know why. :rolleyes5

lrwxrwxrwx 1 root root 18 May 23 17:53 S99-unbrick -> /mnt/cf/unbrick.sh

is the script /mnt/cf/unbrickable.sh itself executable ?

Could all the "unbrickable" (or "brick resistant") directions be consolidated in the wiki, please? I'm not sure I have a correct and complete set of directions.

Hi, everyone. I recently was granted shell access by the kind folks at Irex but I am having a bit of trouble getting started hacking my Iliad. I have been reading these forums for a few hours and it seems as though I am missing some sort of crucial first step.

You see, I was expecting to be able to mount my Iliad using USB and then just cd .. until I got to / (root), and then just drop an ssh client (dropbear or something) in init.d so I could login at my leisure after next bootup. My problem is, however, when I mount the Iliad as a USB drive, the topmost directory seems to be the one containing the content folders (newspapers, books, notes, etc.) Am I in some sort of chroot jail?

As anyone can see, I am missing something very obvious. Any help would be appreciated.

Thanks,

Dorian

Hi, everyone. I recently was granted shell access by the kind folks at Irex but I am having a bit of trouble getting started hacking my Iliad. I have been reading these forums for a few hours and it seems as though I am missing some sort of crucial first step.

You see, I was expecting to be able to mount my Iliad using USB and then just cd .. until I got to / (root), and then just drop an ssh client (dropbear or something) in init.d so I could login at my leisure after next bootup. My problem is, however, when I mount the Iliad as a USB drive, the topmost directory seems to be the one containing the content folders (newspapers, books, notes, etc.) Am I in some sort of chroot jail?

The USB connection only exposes the internal storage area (with books, docs, notes, news). Which makes sense, as exposing / would be a disaster for most people.

The best way to go is to install the unbrikcable package. Then you connect to your network (automatically using cable and dhcp at boot), and you can then ssh to the iliad (using rootme as password), change the password and/or set up ssh keys for easier login.

If you don't want to use cable, create a connect_to_my_wlan.sh containing something like "wireless.sh start <myssid> <mypasswd>" (detailed and correct instructions can be found somewhere in this forum), place it in e.g. "News" and run it.

Hope this helps

You see, I was expecting to be able to mount my Iliad using USB and then just cd .. until I got to / (root), and then just drop an ssh client (dropbear or something) in init.d so I could login at my leisure after next bootup.
Remember to be extremely careful in editing init.d or anything startup-related! If the iliad fails to boot properly it is bricked and that is not something you want happen... the unbrickable package helps, as it starts sshd (dropbear) and connects to LAN with dhcp, but it is not a full protection.

Thanks, you are really beginning to bridge the gaps in my understanding. I think with this new knowledge I can get something going here. Now, I have seen much mention of this wireless.sh script floating around on these forums, along with wired.sh as well. Are these scripts that have already been written and included in my $PATH? Or do they exist outside of my $PATH and need to be referenced directly? Or are they something that I need to try and write myself?


Dorian

Thanks, you are really beginning to bridge the gaps in my understanding. I think with this new knowledge I can get something going here. Now, I have seen much mention of this wireless.sh script floating around on these forums, along with wired.sh as well. Are these scripts that have already been written and included in my $PATH? Or do they exist outside of my $PATH and need to be referenced directly? Or are they something that I need to try and write myself?

They are already there, and in your path (IIRC). Did you manage to connect to your iliad using ssh yet?

The USB connection only exposes the internal storage area (with books, docs, notes, news). Which makes sense, as exposing / would be a disaster for most people.

Indeed. On the other hand, if the whole file system were available via USB mount, many common bricking scenarios could be easily corrected.

My preference would be an option where attaching while pressing some button (or combination thereof) would cause the root partition to mount instead. Perhaps also modifying the boot process to detect very early-on if the iLiad is USB attached and said button pressed, it should directly mount the root file system rather than attempt normal startup.

Indeed. On the other hand, if the whole file system were available via USB mount, many common bricking scenarios could be easily corrected.

Hm... only if the important system files (enough to make the iliad boot and expose the said root system!) were protected from "unauthorized" modification. I guess this is the job of a boot loader, not a USB connection. So perhaps after the CF-reflash-function is completed, but until then they have to play it rather safe.

Dear,

I'm a newbie of iLiad, and thus, I found that the unbrickable package does not help me so much.

How can I uninstall the unbrickable?

Thanks.

So thoughts on how to create an 'ssh on / ssh off' item in the Device Manager content list? I was thinking I could just create script that tested for the existence of S99-unbrick and remove it for off and link to the scripts for 'on'. With changes to the XML files as well to show what it will do if you click it. Thoughts?

--Chuck

Question:

Why would you want to NOT have the unbrickable package? You won't notice it's there anyway and it does not do any harm to have it in my opinion...

Dear,

I'm a newbie of iLiad, and thus, I found that the unbrickable package does not help me so much.

How can I uninstall the unbrickable?

Thanks.

I'm not sure what you're expecting from it. It does nothing at all in normal use of the machine - it's completely transparent and invisible to you. It only comes into play if you somehow corrupt your iLiad's file system or delete something vital. In that circumstance, if you have it installed, you have a way of bringing your iLiad back to life; without it, you'll have no choice but to send your iLiad back to iRex to be repaired, and be without it for weeks, at a minimum.

Now you tell me, is it sensible to have it installed, or not?

I'm not sure what you're expecting from it. It does nothing at all in normal use of the machine - it's completely transparent and invisible to you. It only comes into play if you somehow corrupt your iLiad's file system or delete something vital. In that circumstance, if you have it installed, you have a way of bringing your iLiad back to life; without it, you'll have no choice but to send your iLiad back to iRex to be repaired, and be without it for weeks, at a minimum.

Now you tell me, is it sensible to have it installed, or not?

Actually, I think you may be cofusing this package, with the one provided by iRex.

The package this thread is talking about, setups up remote access to your iLiad so that you can access the filesystem from your PC to make changes or fix problems if something goes wrong.

The package that's included in the Shell access for 2.11 gives you the ability to reflash your iLiad from a compactflash card in the event of a software issue.

The later is more useful to the average user, and neither package conflicts with one another. However, the package in this tread can cause the battery to drain a little faster because wireless lan and an extra pocesss is running all of the time.

Yes, I agree with Adam. It used to be that the 'unbrickable' package was the only way to recover if something went wrong with your iLiad. Now that iRex includes the 'reflash from CF' feature with shell access, the 'unbrickable' package isn't necessary for that.

Instead, 'unbrickable' is a very easy way to access the iLiad's filesystem by logging on via SSH. Once 'unbrickable' is installed, every time your iLiad boots it will turn on wired (or wireless?) networking and start an SSH server. If you plug into your network, you'll be able to log in as root over SSH.

The drawback to this is that having wired/wireless networking running draws some extra power. Since 'unbrickable' is set to run them automatically at boot, you have to turn them off manually if you want to save power.

In my opinion, if you're not a developer, there's no reason to install 'unbrickable'. If you're in a position to mess up your iLiad, then you already have the iRex reflash tool installed anyway.

So if I create a manifest file in the display manager area it seems like I can add the ability to set / reset SSH access. However I can't find any documentation on how to do the device manager UI thing. Anyone have any pointers to an example?

Also wish there was a way to detect light from the front of the Iliad, then you could create a "printer" by putting it into a copy machine and telling the copy machine to make 10 or 20 copies (depending on document length) and each time the Iliad "saw" the light go by it could change to the next page. :cool:

--Chuck

Actually, I think you may be cofusing this package, with the one provided by iRex.

The package this thread is talking about, setups up remote access to your iLiad so that you can access the filesystem from your PC to make changes or fix problems if something goes wrong.

The package that's included in the Shell access for 2.11 gives you the ability to reflash your iLiad from a compactflash card in the event of a software issue.

The later is more useful to the average user, and neither package conflicts with one another. However, the package in this tread can cause the battery to drain a little faster because wireless lan and an extra pocesss is running all of the time.

Ah, my mistake; thank you for the correction. I was indeed talking about the iRex shell access package. I didn't know that there WAS another!

Thanks for putting me right, and apologies for the confusion.

Calling
ifdown eth0
will completely unload unbrickable?
Ethernet will still be available, for example, for updating?
Don't I have to kill dropbear to save the most possible memory ?

Finally, can I remove unbrickable from the start process?
If I do so, is it possible to create a script which starts unbrickable after the iLiad has booted?

Many questions, hope to have a lot of answers. :)

There is an older thread (http://www.mobileread.com/forums/showthread.php?t=15262) about this.

A good description of how it works: Changing or adding system start-up services (http://books.google.com/books?id=2S3eUgb39C8C&pg=PA182&lpg=PA182&dq=%22etc+rc5+d%22&source=web&ots=muKsuAt6CK&sig=87jzKklqNBvJ_LtrHeCj-d-MJQc)

These are the files unbrickable places in the system:
/usr/bin/dropbear
/usr/bin/scp
/etc/dropbear/
/etc/dropbear/dropbear_dsa_host_key
/etc/dropbear/dropbear_dss_host_key
/etc/network/interfaces
/etc/init.d/dropbear
/etc/rc5.d/S98dropbear
/etc/passwd

If you want to get rid of it, just delete all of them but /etc/network/interfaces and /etc/passwd.

If you want iLiad to stop starting the daemon at start-up, just delete the symbolic link /etc/rc5.d/S98dropbear , which points to the script, /etc/init.d/dropbear , that starts/stops it.
Then
/etc/init.d/dropbear start
to start, and
/etc/init.d/dropbear stop
to stop.
Or create .sh files as described in the thread (http://www.mobileread.com/forums/showthread.php?t=15262) I mentioned above.

There is an older thread (http://www.mobileread.com/forums/showthread.php?t=15262) about this.

A good description of how it works: Changing or adding system start-up services (http://books.google.com/books?id=2S3eUgb39C8C&pg=PA182&lpg=PA182&dq=%22etc+rc5+d%22&source=web&ots=muKsuAt6CK&sig=87jzKklqNBvJ_LtrHeCj-d-MJQc)

These are the files unbrickable places in the system:
/usr/bin/dropbear
/usr/bin/scp
/etc/dropbear/
/etc/dropbear/dropbear_dsa_host_key
/etc/dropbear/dropbear_dss_host_key
/etc/network/interfaces
/etc/init.d/dropbear
/etc/rc5.d/S98dropbear
/etc/passwd

If you want to get rid of it, just delete all of them but /etc/network/interfaces and /etc/passwd.

If you want iLiad to stop starting the daemon at start-up, just delete the symbolic link /etc/rc5.d/S98dropbear , which points to the script, /etc/init.d/dropbear , that starts/stops it.
Then
/etc/init.d/dropbear start
to start, and
/etc/init.d/dropbear stop
to stop.
Or create .sh files as described in the thread (http://www.mobileread.com/forums/showthread.php?t=15262) I mentioned above.

Thank you, great answer, it works.
But I have another question:
eth0 is always on, is dropbear that starts it or is there a script starting it which comes with the unbrickable installation?
It is a problem for me because in the third case I have to know how to prevent eth0 from turning on. I don't want to do
ifdown eth0
every time I turn on th iLiad.

In
/etc/network/interfaces
delete the following text:
---
auto eth0
iface eth0 inet dhcp
...
pre-up modprobe smc91x
post-down rmmod smc91x
---
but leave
---
auto lo
iface lo inet loopback
---

Then, in order to start LAN (eth0) use:
wired.sh start
and to stop it:
wired.sh stop

After you have edited /etc/network/interfaces ,
ifup/ifdown eth0
will no longer work.

I've gone ahead and set it up into an installable ipkg file. Simply unzip, copy and run.


Hi, I have installed Adam's package and since then I am no longer able to establish any network connection with my Iliad (LAN & Wlan). Needless to say that shh is impossible either. Any idea how to solve this?

Regards
Harald

"/usr/bin/wired.sh" and "/usr/bin/wireless.sh" are two useful script to manage internet connection. The following is the usage:

wiredUsage()
{
echo "Usage:"
echo " $0 stop"
echo " $0 start [dhcp]"
echo " $0 start static <ip-address> <netmask> <broadcast-addr> <gateway-addr> <nameserver-addr>"
echo " $0 mac"
echo "Note: NFS safe"
exit 1
}

wirelessUsage()
{
echo "Usage:"
echo " $0 stop"
echo " $0 start <ssid> [enc <wepkey> | wpa <psk>]"
echo " $0 scan [<ssid>]"
echo "Note: always dhcp"
exit 1
}

for wap, the <psk> is the plain phrase you set, such as "password", not encrypted key.

"/usr/bin/wired.sh" and "/usr/bin/wireless.sh" are two useful script to manage internet connection.
How do I access those scripts without network connection to establish ssh?

Regards

Here is a package I prepared for my own convenience. Maybe it will save some peopel's precious time. This package won't copy any file to your iLiad. All your have to do is change root password.

prerequisite:
1. Have installed developer's package.
2. Have a mrxvt in your memory card.
3. Your router offers DHCP service.

Install:
1. Unzip the attached file to any place in your memory card. After unzipped, a directory "sshd" should emerge.
2. In mrxvt, execute "passwd" to change your root password. There is no old password. Just type your new password twice.
3. You can run dropbear with wired connection now. In your contentlister, go to "sshd", tap on "Enable SSH - wired". If everything goes well, you can connect iLiad from your PC using PuTTY. If you are not sure the ip address of Iliad, type "ifconfig" in mrxvt. Login with root and password.
4. For wireless connection, you have to modify "sshd\ssh-wlan-enable \run.sh" in the package. Find the line:
/usr/bin/wireless.sh start YOUR_SSID wpa YOUR_Pre_Shared_Phrase
Replace "YOUR_SSID" with the ssid you set on your wireless AP.
For wpa, just replace "YOUR_Pre_Shared_Phrase" with plain password text (not hex code).
For wep, replace "wpa" with "wep", and replace YOUR_Pre_Shared_Phrase" with hex code.
Then your can run dropbear with wireless connection.
5. To stop dropbear and wired/wireless connection, tap on "Disable SSH" in your contentlist.

Note:
I only tested it with wireless wpa connection. For wep users, please test it yourself. I didn't test it with wired connection. But I think it should be working fine with wired connection.


Edited:
Although scp is included in my package, I didn't set PATH to it. scp cannot be called before PATH is set. If you use WinSCP, you can set PATH in command toolbar in WinSCP after connect to iLiad using ssh.

Here is a package I prepared for my own convenience. Maybe it will save some peopel's precious time. This package won't copy any file to your iLiad. All your have to do is change root password.

Hi ericshliao, and thank you very much for this extremely helpful solution!!
:thanks:
Regards
Fodiator

May I say thanks ericshliao also. I tried it out with WPA and it worked like a charm.

-Ksira

Wep works like a charm! Thanks, Eric :)

One question though, The iLiads IP address is not 10.0.0.200. So, I guess it's dynamic, not static.
Oh, and do I have to use Putty? Doesn't gnome-terminal/Konsole have support for OpenSSH?

Is it only possible to connect with ethernet? I only have wireless connectivity, and even though dropbear is running, I still haven´t been able to connect to my iliad via ssh

WEP works here. According to earlier responses WPA works great too.