Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Wed Jan 17, 2018 3:41 pm

All times are UTC+01:00

Post new topic  Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Tue Nov 01, 2016 10:41 pm 
Total Newbie

Joined: Tue Nov 01, 2016 4:36 pm
Posts: 2
So I guess this is an unusual model for enthusiasts to be fiddling with, as I have been struggling to find info while beating one into submission recently. I also appreciate it's 2016 and I'm a bit late to the party! However I have made a very useful firmware for this model now, which enables root access, sshd and also resolves a bug inherent to the design of the unit when you share an iSCSI volume and create LVM volumes on it, the Terastation removes the LUN on next boot.

Will post more info tomorrow.

PostPosted: Wed Nov 02, 2016 10:53 am 
Total Newbie

Joined: Tue Nov 01, 2016 4:36 pm
Posts: 2
Terastation Pro 2 iSCSI TS-IGL and Terastation Pro 2 iSCSI Rackmount TS-RIGL

This model is an ARM9 based unit with the same board as the TS Live TS-DHTGL (maybe) and TS Pro 2 TS-HTGL/TS Pro 2 Rackmount TS-RHTGL (definitely) but with a much reduced software set. It stayed on firmware 1.01 instead of being upgraded through the years like the TS Pro 2. You seem to be able to convert a TS-RITGL to a TS-RHTGL and back again via firmware updates.

The reduced software set means that the device does not respond to ACP commands that aren't firmware updates. So acp_commander is out, NAS Navigator doesn't work, etc. This is basically confirmed here: viewtopic.php?t=7936. There also doesn't appear to be a TFTP recovery image for the device (as per http://forums.buffalotech.com/index.php?topic=2786.0) although it will boot into TFTP recovery mode with a bit of prodding (blanking all the drives seems to work). It will load the TFTP recovery from a TS Pro 2, but then the TSUpdater for the rackmount model doesn't see the device as an RIGL so won't upload the full RIGL firmware onto it. The reduced software set seems to have removed some Kerberos libraries, which prevent SSHD from working. SSHD is there with config files, init scripts etc, but it cannot start in stock form due to missing dependencies.

The Big Problem
The device also has a humungous bug involving Linux LVM2. We use our TS Pro iSCSI with Citrix Xen to host virtual machines. Xen stores VMs within LVM VolumeGroups, each Xen storage repository (SR) is an LVM filesystem over iSCSI (lvmoiscsi in Xen) with a volume group (VG) matching the UUID of the Xen SR. Each Xen virtual disk (VDIs) is then created as an LVM logical volume (LV) within the volume group (VG) along with a 4MB management volume called MGT. Unfortunately because the Terastation also runs Linux and also runs LVM, when the device reboots the local LVM process sees the VG created by Xen and activates it as drives locally on the Terastation. This means that the iSCSI target process (ietd) on the Terastation cannot exclusively lock the data to share it over iSCSI and cannot allocate a LUN to the volume. There is a web interface option for not using LVM to manage the Volumes shared from the Terastation, but it does not prevent this error, it just stops your iSCSI volume from being resizeable.

TL;DR If you use a Terastation iSCSI with Xen, you can connect a software iSCSI storage repository and store virtual disks on it, but when the Terastation reboots the LUN will no longer be available to Xen and the SR will fail.

Useful info common with other Terastation models

As per this page you can easily get a serial console from the unit: http://buffalo.nas-central.org/wiki/Serial_console_TsP
From the serial console you can log in as admin with the same password as the web interface but you are fairly limited to what you can do. The iSCSI firmware doesn't have any of the immediately obvious exploitable bugs shown here: http://buffalo.nas-central.org/wiki/Ter ... ecome_root
If you brick the device, or want to recreate the filesystem or fit larger drives, this process works great under the "Terastation Pro v2, Terastation Live" heading, except I didn't use xfs I used ext3 for all partitions: http://buffalo.nas-central.org/wiki/Rev ... om_scratch - as usual you get initrd.buffalo and uImage.buffalo along with hddrootfs.buffalo.updated from the stock firmware.

Data Recovery Hints
I had a Xen LVM filesystem that I needed to recover from a Terastation that had the aforementioned bug. As the drive array is a Linux multiple-devices (md) array it was fairly easy to do. I found a PC with 4 SATA ports. Installed XenServer onto a USB drive. Connected the 4 drives from the Terastation to the motherboard of the PC. Powered up Xen and went to the command line. Issued:

# modprobe md_mod

To load the multiple-devices kernel module. Issued:

# mdadm --assemble --scan

To autodetect the raid arrays from the terastation. The arrays came in as /dev/md125 (/boot on the TS) /dev/md126 (/ on the TS) and /dev/md127 (the RAID5 array with the data on). From there issuing commands like 'vgs' 'lvs' showed the Xen storage repository and so I added the RAID5 array from the TS as a local storage repository to my new Xen server with this process, substituting the disk device with /dev/md126: https://support.citrix.com/article/CTX121313 - because the data is now local the SR type changes from lvmoiscsi to plain lvm. Hey presto, my VDIs appeared in XenCenter and I could export them to safety.


As the device only ever received one stock firmware update (1.01-116) available here: http://www.buffalo-technology.com/downl ... php?r=3940 - serial console works but that's about it. Unfortunately to be able to 'fix' the Terastations local LVM I need to be root.

I fairly quickly found this firmware image: http://www.moreau37.fr/terastation-ritg ... ware-1-16/ which claims to enable telnetd and reset the root password to be the same as the admin password. In my experience it didn't quite work like that (/etc/init.d/rcS seems to just set the root password to 'password') but I was still unable to log in as root. So after flashing this I have gained telnet but not a lot else. I then spent ages going round in circles editing /etc/shadow offline, editing it in /boot/conf_save.tgz etc. Nothing worked. Eventually I made my own firmware using "George's Script Method" from: http://buffalo.nas-central.org/wiki/Open_Stock_Firmware There are a few bugs with this script which I have fixed, these are detailed further down the page.

However this still didn't get me root - telnetd will not let you log in as root, and su - doesn't work either in the stock firmware or the moreau37 firmware above. After days chasing my tail I discovered that the /bin/su binary is missing it's setuid bit (chmod +s) so it's unable to elevate you to root. Helpfully it reports this as 'invalid password'.

By now I am fairly adept at my own firmware changes. I have taken the stock firmware from Buffalo linked above and made these changes:

[*]Restore setuid bit on /bin/su so that su works as intended
[*]Added the following library files from a Linkstation Pro Duo firmware (also ARM9) to support SSH:
These files were taken from LS-WTGL_fw3.09 http://www.buffalo-technology.com/downl ... php?r=4048
[*]Edited /etc/init.d/rcS script to:
    If the root password is set to password, reset it to match the admin password. I don't want people using my firmware to be compromised because they forgot to set their root password to something sensible, this method means that people who don't really know what they're doing will still change the root pw from its default via the web interface
    Removed lvm.sh from the list of startup scripts. It's still there if you want to start it manually but I think with iSCSI you want to pass the filesystem through to the initiators uninterrupted, without the local OS having access
[*]Edited the /etc/init.d/sshd.sh startup script to generate new server keys if they don't exist. It's normal Linux behaviour to generate unique SSH keys on first-boot so that your server is uniquely identified, but Buffalo have a set of 'default' keys pre-installed on their device, so all Terastation Pro iSCSI devices have the same identity. This easily enables a variety of attacks and is a security risk. This way, the first time your Terastation starts my firmware it generates its own security keys.
[*]Edited the /etc/sshd_config file to enable loading of SSH2 keys (without which only SSH1 works, no SFTP etc) and disable root login via SSH - with a working su binary you shouldn't be logging in remotely as root
[*]Added libproc, joe from the addons.tar file along with an appropriate joerc structure and the full-blown ps binary from http://buffalo.nas-central.org/wiki/Open_Stock_Firmware (Optional Files & Fixes section)
[*]Set permissions correctly on /dev/null, /etc/profile, /dev/tty and /var/log/lastlog as per: http://buffalo.nas-central.org/wiki/Open_Stock_Firmware (Optional Files & Fixes section)
[*]Added sshd to daemonwatch as per: http://buffalo.nas-central.org/wiki/Open_Stock_Firmware (Optional Files & Fixes section)

So this firmware is essentially designed to take a nearly-very-useful device and turn it into a very-useful device with a few less bugs.

Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 2 posts ] 

All times are UTC+01:00

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited