Difference between revisions of "Open Stock Firmware LS-XHL"
(→Why a new page for the XHL?)
(→The step by step guide)
|Line 171:||Line 171:|
After a while (depending on the speed of your PC) you can find the patched hddrootfs.img in directory "unpack/open".
After a while (depending on the speed of your PC) you can find the patched hddrootfs.img in directory "unpack/open".
Revision as of 07:59, 28 February 2010
- 1 Important
- 2 Why a new page for the XHL?
- 3 Is this working for the CHLv2 also?
- 4 What to do first in case of upgrading from 1.10?
- 5 How to get the executables from release 1.10 if you already upgraded to 1.20?
- 6 How to get telnet working in 1.20
- 7 How to get telnet working in 1.24 or any other LS-XHL or LS-CHLv2 version
- 8 How to convert the data partition from XFS to EXT3?
Please read the complete guide, even if you already have a box with firmware greater 1.10. Only the chapter about the conversion of the filesystem is optional. Everything else is NOT.
The tool acp_commander is used. You can find the readme here: http://downloads.buffalo.nas-central.org/TOOLS/ALL_LS_KB_ARM9/ACP_COMMANDER/README .
You will find the link to the library further down this guide.
What will you have to do during this guide?
- You will have to copy some files to your LS onto a share named "share".
- You have to get access to the LS via acp_commander in interactive mode.
- You will have to use some Unix commands to copy files and to set file mode bits.
Why a new page for the XHL?
Unfortunately to open the firmware of a XHL depends on the release of the firmware currently running on the machine.
The XHL firmware above release 1.10 do NOT contain telnetd or sshd anymore. So acp_commander can not enable telnet access due to the lack of the executable. Unfortunately acp_commander cannot detect this and erroneously reports success.
If you have firmware 1.10 or lower, you should be able to follow the hints in Open_Stock_Firmware to get telnet access, except that you should not use the addons.tar, because the executables within will NOT work on the LS-XHL. You do not need the addons.tar for enabling telnet access. But with firmware 1.20 luck is not on your side.
Even worse for version 1.24 this will not work at all, because the acp_commander is not working anymore. You can connect via acp_commander but you will not be able to execute any command although you will not get error messages. You will have to open the firmware by flashing a new firmware which you "opened" before manually. I wrote a small guide which you can find below.
Attention: What ever you do, you do it on your own risk
Is this working for the CHLv2 also?
The LS-CHLv2 has the same CPU as the LS-XHL. It differs in CPU frequency and amount of memory. So the executables should be interchangeable (the GPL source from Buffalo for the XHL and CHLv2 is identical -> it is the same directory at their server).
There are already several success stories for following this guide to "open" the LS-CHLv2.
What to do first in case of upgrading from 1.10?
If you want to upgrade the firmware from 1.10 to something newer, you should take care of some things before, or you will loose the ability to get telnet access to your XHL.
The assumption is, that you have a share called share and you already opened the LS for telnet access using Open_Stock_Firmware.
- You already should have acp_commander.jar. If not: http://downloads.nas-central.org/TOOLS/ALL_LS_KB_ARM9/ACP_COMMANDER/acp_commander.jar.
- Save some executables from the 1.10 firmware:
mkdir /mnt/disk1/share/xhl cd /mnt/disk1/share/xhl mkdir bin cp /bin/su bin/ mkdir -p usr/local/bin mkdir -p usr/local/sbin cd /mnt/disk1/share/xhl/usr/local/sbin cp /usr/local/sbin/telnetd . cp /usr/local/sbin/sshd . cd /mnt/disk1/share/xhl/usr/local/bin cp /usr/local/bin/ssh* . mkdir -p etc/init.d cd /mnt/disk1/share/xhl/etc/init.d cp /etc/init.d/sshd.sh .
Now you are prepared to upgrade to 1.20 or higher.
How to get the executables from release 1.10 if you already upgraded to 1.20?
Get the firmware release 1.10 from Buffalo: http://www.buffalo-technology.com/support/getfile/?lsxhl-110.zip
Unpack the zip and unzip hddrootfs.img then. Use the password:
Now you can copy the extracted executables to your XHL share.
Alternatively you can download this file: http://downloads.buffalo.nas-central.org/Users/kenatonline/xhl-110-telnet-ssh-clearaddon.tar.gz
It contains the executables and a patched (unnecessary binaries removed) addons.tar which you can copy into your acp_commander directory. The excutable "su" is still part of this, in case you already used the addons.tar from acp_commander (via automatic download). It also contains the optware bootstrap file for the Marvell Kirkwood feed.
Copy these files to your share "share". The directory structure should look like this on "share":
How to get telnet working in 1.20
The assumption is, that your XHL is already running firmware 1.20 and that you are aware of handling command line executables and stuff like this, if you are used to a Unix flavor. For the windows noobs I will add some windows hints also.
- Disable the XP/Vista/7 firewall or you will get sockettimeout errors.
- Start a command line via "Start" - "Run" - "cmd.exe". Everything else is done within the command line window.
- Ensure you have a valid java installation by checking the version:
- Change to the place where you placed acp_commander.jar (I assumed it is on c:\tmp\xhl\) via:
- Get into an interactive acp_commander session (all commands will be executed as root in interactive mode and all parameters are necessary):
java -jar acp_commander.jar -t <XHL IP address> -ip <XHL IP address> -pw <password of the web admin user> -s
example: java -jar acp_commander.jar -t 192.168.1.10 -ip 192.168.1.10 -pw secret -s
- In interactive mode you should do the following (attention: cd does not work in interactive mode!):
cp /mnt/disk1/share/xhl/usr/local/sbin/telnetd /usr/local/sbin/ ln -s /usr/local/sbin/telnetd /usr/sbin/telnetd cp /mnt/disk1/share/xhl/usr/local/sbin/sshd /usr/local/sbin chmod 4555 /bin/su echo "telnet stream tcp nowait root /usr/sbin/telnetd /usr/sbin/telnetd" >> /etc/inetd.conf chmod 644 /etc/profile reboot
Now your XHL should reboot. After a minute or so, you should be able to telnet to your XHL using the user admin (the same admin you use to access the web configuration of your XHL).
I haven't found a way to let root login via telnet, but you can simply call
after logged in as user admin, to switch to user root (do not forget the "-" or you won't have any PATH environment set!).
The installation of the addons.tar is identical to the non-XHL LS-PRO except that /bin/su will get overridden by a version within the addon.tar which is not working properly. So you have to get into the acp_commander interactive mode again after the installation of addon.tar. Do the following:
java -jar acp_commander.jar -t <XHL IP address> -ip <XHL IP address> -pw <password of the web admin user> -s cp /mnt/disk1/share/xhl/bin/su /bin/ chmod 4555 /bin/su
Now you should have telnet access to your XHL. Have fun!
How to get telnet working in 1.24 or any other LS-XHL or LS-CHLv2 version
Due to the circumstance that buffalo changed a third time the way to "open" a firmware, I decided to make a guide which will help others to open any firmware version.
How will it work?
We will patch the firmware directly before we update the firmware of the box. Nevertheless you can use this method for "opening" the same version of firmware you are already running on your box.
Some executables are missing within the latest firmwares. I collected the missing executables from the 1.10 firmware and put them into a single tar file. http://downloads.buffalo.nas-central.org/Users/kenatonline/OpenFirmware/executables.tar.gz
To make the patching easier, I wrote a small script doing the "whole" work. http://downloads.buffalo.nas-central.org/Users/kenatonline/OpenFirmware/open_firmware.sh
For emergency purposes, I added the call to a script into a script started at bootup of the box. It is called in step 4 of the rcS via a standard Buffalo mechanism (/etc/init.d/extensions.d). The advantage of this is, that you can put a script onto the "share" share and simply reboot the box to have the possibility to execute commands as the superuser.
The script to place on the share "share" is named "emergency.sh".
I made some examples for the usage of the emergency script.
One to reset the root password to empty. http://downloads.buffalo.nas-central.org/Users/kenatonline/OpenFirmware/freerootpw.sh
One to enable the ssh daemon. Of course you can call this script as well on the box directly when logged in as superuser. http://downloads.buffalo.nas-central.org/Users/kenatonline/OpenFirmware/enablesshd.sh
Just copy one of this scripts to the share "share" and rename them to "emergency.sh". Take care that you set the execution bit of the script for superuser at least!
Be aware that this script gets executed EACH TIME you reboot. So remove the file after the reboot, if it is a One-Shot one ("One-Shot" means: it makes no sense or harms something if run more than once). So it makes no sense to leave the freerootpw.sh as "emergency.sh" there, because the password would get reset after each reboot!
Bells and Whistles
Each *.tar file and each *.key file can get included into the patched firmware. Just put the files in the same directory as the firmware zip and the open_firmware.sh script.
The *.tar can contain anything you like to have within the firmware. The file will be unpacked in the virtual root directory of the hddrootfs. So if you want to have an additional file ending in "/usr/sbin" of the firmware, you have to put it into "usr/sbin/" within the tar file.
The *.key files will get added into the "authorized_keys" file of the superusers ".ssh" directory. You can then use this keys to connect as root via ssh.
The step by step guide
Download the firmware zip from Buffalo. Then determine the password which has to be used to unpack the hddrootfs.img.
Edit open_firmware.sh and replace the value of the PASSWORD variable with the matching password. Take care to use a Unix-aware editor.
Unpack exectables.tar.gz so that you get executables.tar.
Start a Linux Live CD on your PC (or take you regular Linux box).
Start a terminal window in Linux and become user "root".
Copy the firmware zip, the open_firmware.sh script and the executables.tar into one directory.
Make the script executable.
chmod 700 open_firmware.sh
Start the script with the name of the firmware zip as parameter.
Please check for error messages during this! An error message saying "No file '*.key' found" is harmless and means that you have not provided a ssh keyfile for integration. After a while (depending on the speed of your PC) you can find the patched hddrootfs.img in directory "unpack/open".
Save the file to an external destination, because you have to leave Linux and to go to a Windows environment (Buffalo offers the Updater for Windows only). Back in Windows, replace the hddrootfs.img of the original firmware with the one from "unpack/open".
Edit the LSUpdater.ini and add this:
Start the firmware updater of Buffalo.
Click left on the two golden rings on the upper left.
Choose the menuitem "Debug(D)...".
Depending if you update from an older version or just open the same version already installed on your box, you have to choose "Force update", "Do not check version".
If you want to overwrite the same version, deselect "Update BOOT", "Update KERNEL" and "Update initrd". You don't need them, because you changed the rootfs only.
Click on "OK".
Verify the settings on the dialog, that you are updating the right box.
The firmware will be transfered to the box. The box will restart. The blue LED will blink steadily. Then the orange LED will blink the sequence two times long and five times short during the update (this is I25 = firmware update). Then again the blue LED will blink steadily.
After a minute, the blue LED will stay on and you should be able to connect via telnet (or ssh). For login via telnet, use the user "admin". This is the same user (and same password) as the user "admin" you use to login to the Web interface.
In principle, this should work with ALL kind of Buffalo firmwares (so this is not restricted to LS-XHL or LS-CHLv2). Of course, if your box has a different kind of CPU, you maybe need different executables. But due to the "Bells and Whistles" this is no problem. Just leave out the executables.tar I provided and place your own tar-file with the appropriate executables into the same directory you placed the open_firmware script.
The internals of the script open_firmware.sh
The script creates a directory structure like this:
unpack ori ROOTFS open
Directory "unpack" is used to unpack the original Buffalo firmware. In directory "ori", the hddrootfs.img will get unpacked. In directory "ROOTFS" the unpacked hddrootfs.img (it is packed twice!) will get unpacked and patched. In directory "open" the resulting hddrootfs.img will get created.
The assumption is, that the original firmware unpacks into its own directory with a name starting with "ls". If this is not true for your firmware, adapt the "unzip -P" in line 19 accordingly.
In line 28-30, the emergency script gets created into directory "etc/rc.d/extensions.d". This directory is used by Buffalo for scripts which should get started in a later stage of the bootup. Why haven't I patched the "/etc/init.d/rcS" instead? Because I wanted to change as few original files as possible. And just for starting scripts during bootup, you don't have to patch /etc/init.d/rcS.
In line 32, telnet gets enabled in inetd.conf.
In line 34, root login via ssh is enabled via a small sed command.
In line 36-37, sshd gets started via the same mechanism we used for the emergency script.
In line 41, an error message due to a wrong filemode during login is prevented.
In line 44-47, correcting missing libraries. Buffalo uses libraries within PAM, which are not provided by them. This links should solve this problem.
In line 50-53, extracting ALL *.tar files located in the starting directory (the one containing the script itself) into the directory "ROOTFS".
In line 55-62, extracting ALL *.key files located in the starting directory (the one containing the script itself) into the directory "ROOTFS/root/.ssh" into a file named "authorized_keys". This is necessary to connect via ssh as user root using public/private key encryption.
In line 65-67, creating of the patched hddrootfs.img into the directory "unpack/open".
How to convert the data partition from XFS to EXT3?
At least with firmware release 1.20, the firmware can handle a ext3 formatted root filesystem as well as a ext3 formatted data partition without "patching" anything serious.
The information of the format of the root filesystem and the data partition seems to be stored in non-volatile ram. There are two applications handling the reading and writing to this storage, named dumpnf and setnf.
If one looks into the initrd.buffalo, he can find a dirctory /root/.nas_features which contains preconfigured information for different linkstation models.
For the following operations you should login as root (su -).
To ensure to take the right information we dump the current content of the storage to a file:
dumpnf > /etc/nas_feature
Now edit the file /etc/nas_feature and change the following setting:
Now one can format the data partition (/dev/disk1_6 aka. /mnt/disk1), but do not forget to save the data before, because you will loose everything on this partition.
umount /mnt/disk1 mkfs.ext3 -m 0 /dev/disk1_6 mount -t ext3 /dev/disk1_6 /mnt/disk1
Now you should restore your saved data.
The last thing we have to do, is saving the changed settings into the non-volatile ram:
setnf < /etc/nas_feature
Atfer a reboot, one should check with:
that he gets this:
rootfs on / type rootfs (rw) /dev/root on / type xfs (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw) /dev/ram1 on /mnt/ram type tmpfs (rw) /dev/sda1 on /boot type ext3 (rw,data=ordered) usbfs on /proc/bus/usb type usbfs (rw) /dev/disk1_6 on /mnt/disk1 type ext3 (rw,data=ordered)
The last line is the important one. It says the format is ext3. Voila.
To change the root filesystem from xfs to ext3 is analog to the former stuff, but one has to get into EM mode to access the partition sda2.
The setting to change is:
Because I decided to change only the filesystem of my data partition to ext3, I do not explain the change of the root filesystem in detail.