NSA310 eternal beeping

Hello Everyone,

Sorry to intrude here with a not (yet?) hacked device, from a not (yet?) linuxhacker (:)), but "you are my only hope".
So I got a NSA310 from a friend, who had it run for several years, when all of a sudden it was unavailable. Upon restarting, after some blinking for 30secs, there was only an eternal beep-beep-beep-.. from the buzzer. This is the situation with the original HDD, a blank new HDD, or no HDD.
He gave it to me, to see if there is some chance of revival, but I am noob in these embedded linux stuff. Sadly most resources (official firmware, usb force update script) got pulled offline after the EOL of the device.
On a whim I bought a CP2012, manage to connect to the device, and seen some messages during boot, see attached.

Some googling upon key words brought me to some threads on this forum - but I am too inexperienced to understand them.

Could you help in answering the following basic questions?
1) Are the bad eraseblock messages blocks, that have been predetermined as bad in factory, or does this means that the NAND is getting worse?
Bad eraseblock 611 at 0x000004c60000
Bad eraseblock 621 at 0x000004da0000

2) what is wrong? :) I mean i see
ls: /zyxel/mnt/nand/sysdisk.img.gz: No such file or directory
NAND Flash Corrupt...
the sys-root image /dev/mtdblock6 is currupt !!
Dual images are currupt !!!
From quickly reading some topics on this forum, i see these also could be substituted from a flash drive using debian images - but is there a way to get the original content back?

3) I found this https://github.com/vch42/NSA3xx-usb-recovery-stick, but this does nothing, i think because
sda
checking sda
Trying to mount /dev/sda1
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
cmd = cat /etc/Zy_Private /mnt/parnerkey/nsa310_fw/usb_key_func.sh | md5sum -c /mnt/parnerkey/nsa310_fw/Upgrade_C0
md5sum: WARNING: 1 of 1 computed checksum did NOT match
md5 check error
Has someone had any luck with this?

4) If the NAND is toast, and transitioning to a debian would be a solution, would this be a usable guide?
https://github.com/peeter123/NSA310-320-debian
The Known Bugs section seems scary:
Samba crashes whole system
Ethernet leds don't work @ 1gbit
All mtd blocks read as bad. The chip is somehow not supported by kernel.

I am thankful for any advice,
Peter

Peter,

> Sorry to intrude here with a not (yet?) hacked
> device, from a not (yet?) linuxhacker (:)), but
> "you are my only hope".

Wellcome! and no worry, we will help users at all level.

> So I got a NSA310 from a friend, who had it run
> for several years, when all of a sudden it was
> unavailable. Upon restarting, after some blinking
> for 30secs, there was only an eternal
> beep-beep-beep-.. from the buzzer. This is the
> situation with the original HDD, a blank new HDD,
> or no HDD.
> He gave it to me, to see if there is some chance
> of revival, but I am noob in these embedded linux
> stuff. Sadly most resources (official firmware,
> usb force update script) got pulled offline after
> the EOL of the device.
> On a whim I bought a CP2012, manage to connect to
> the device, and seen some messages during boot,
> see attached.

Good move! the first thing to do when unbricking a device is connecting serial console.

>
> Some googling upon key words brought me to some
> threads on this forum - but I am too inexperienced
> to understand them.
>
> Could you help in answering the following basic
> questions?
> 1) Are the bad eraseblock messages blocks, that
> have been predetermined as bad in factory, or does
> this means that the NAND is getting worse?
> Bad eraseblock 611 at 0x000004c60000
> Bad eraseblock 621 at 0x000004da0000

No, NAND flashs often have bad blocks. You'll often see new devices with a few bad blocks coming out of the factory. That does not mean it is going bad. Only when the bad blocks increase over time, then it's going bad.

These 2 bad blocks are farther in NAND, not at the beginning (where u-boot bootloader is), so there is nothing to worry about.

>
> 2) what is wrong? :) I mean i see
> ls: /zyxel/mnt/nand/sysdisk.img.gz: No such file
> or directory
> NAND Flash Corrupt...
> the sys-root image /dev/mtdblock6 is currupt !!
> Dual images are currupt !!!

Those errors most likely because the system rootfs is in mtd6. Once you examined the mtds definition for this box then you'll be able to confirm that.

Kernel command line: console=ttyS0,115200 mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) root=/dev/nfs rw init=/init

That shows the rootfs1 is in mtd6.

> From quickly reading some topics on this forum, i
> see these also could be substituted from a flash
> drive using debian images - but is there a way to
> get the original content back?
>

It is possible, but with a bit or a lot of works. That you'll find out after you have booted the box with Debian on USB rootfs.

> 3) I found this
> https://github.com/vch42/NSA3xx-usb-recovery-stick,
> but this does nothing, i think because
> sda
> checking sda
> Trying to mount /dev/sda1
> FAT: utf8 is not a recommended IO charset for FAT
> filesystems, filesystem will be case sensitive!
> cmd = cat /etc/Zy_Private
> /mnt/parnerkey/nsa310_fw/usb_key_func.sh | md5sum
> -c /mnt/parnerkey/nsa310_fw/Upgrade_C0
> md5sum: WARNING: 1 of 1 computed checksum did NOT
> match
> md5 check error
> Has someone had any luck with this?

I'm not sure what's wrong there. It's been too long ago since I see this recovery procedure.

>
> 4) If the NAND is toast, and transitioning to a
> debian would be a solution, would this be a usable
> guide?
> https://github.com/peeter123/NSA310-320-debian
> The Known Bugs section seems scary:
> Samba crashes whole system
> Ethernet leds don't work @ 1gbit
> All mtd blocks read as bad. The chip is
> somehow not supported by kernel.

As I mentioned, NAND is OK.

====

So what we do here is to install new u-boot and latets Debian kernel to run these boxes. We will ignore stock FW. Here are steps you should follow.

1. Unbricking

With serial console module connected on another Linux host, run kwboot to boot the box. This is to ensure you have a recovery path when something went wrong.

https://forum.doozan.com/read.php?3,51739,51919#msg-51919

The post above was written for Zyxel NSA320S. So everything is the same for this Zyxel NSA310, but the u-boot image you need to use is different.

U-Boot release thread:
https://forum.doozan.com/read.php?3,12381

Download this tarball: uboot.2017.07-tld-1.nsa310.bodhi.tar

And follow the rest of the instruction to run kwboot.

2. After you have successfully run kwboot to boot this box. Proceed to prepare the USB rootfs using Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2 from the release thread:

Kernel and Debian rootfs release thread:
https://forum.doozan.com/read.php?2,12096

(Scroll down to section 01 Nov 2023 )

3. We'll continue after you're done 1 and 2.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 11/26/2023 05:58PM by bodhi.

Hi Bodhi,

Sorry for the late reply, i had some trouble with the CP2102 module. When connecting the wires, but before powering up the NAS, i got some garbage characters in the terminal. While the device was on, this was not a problem, but kwboot started transmitting immediately after connecting.
But luckily i read in some thread, that a raspberry pi can be used directly, and I could borrow one, so I could try what you wrote.

Your instructions were great, I have downloaded the kwb, and with

kwboot  -t -B 115200 /dev/ttyAMA0 -b uboot.2017.07-tld-1.nsa310.mtd0.kwb -p

I was able to see the boot process.
After that I have downloaded the rootfs, extracted, inserted it, and booted. You can find the log attached. I think it was successful. :)
The odd thing is, that there were some errors, that eth0 could not be started. Could this be because it is now called enp1s0?

BR,
Peter

Peter,

> I was able to see the boot process.
> After that I have downloaded the rootfs,
> extracted, inserted it, and booted. You can find
> the log attached. I think it was successful. :)

Fantastic!

> The odd thing is, that there were some errors,
> that eth0 could not be started. Could this be
> because it is now called enp1s0?

Yes, right on.

2: enp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:30 brd ff:ff:ff:ff:ff:ff

So you need to change eth0 to enp1s0 in /etc/network/interfaces.

auto lo enp1s0
iface lo inet loopback
iface enp1s0 inet dhcp

And during boot, u-boot prints out several warning messages, they are not errors.

## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0

## Unknown partition table type 0
loading envs from usb 0 ...
** File not found /boot/uEnv.txt **

no IDE devices available

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

OK, thanks, a quick edit and a /etc/init.d/networking restart later i have connectivity

root@debian:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:00:00:00:30 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.156/24 brd 192.168.1.255 scope global dynamic enp1s0
       valid_lft 14396sec preferred_lft 14396sec
    inet6 2001:4c4e:181f:3b00:200:ff:fe00:30/64 scope global dynamic mngtmpaddr
       valid_lft 3595sec preferred_lft 3595sec
    inet6 fe80::200:ff:fe00:30/64 scope link
       valid_lft forever preferred_lft forever
root@debian:~#

And i can now SSH directly into the NAS, which looks promising.
I managed to find the latest 4,70 FW and the NAS Setup Utility in a forum. Sadly the NSU does not discover the NAS despite its IP.
Is there a way to reflash the latest FW over SSH?

> Is there a way to reflash the latest FW over SSH?

Yes you can. But why stay with stock FW? they are old and unsecure. You can run Debian now.

But I do understand there are other reasons one might want to do that. For example, you want to sell the NAS.

To flash stock FW, you just log into Debian and use flash_erase and nandwrite similar to how you flash the new u-boot. But the stock FW must have each of the mtds in a separate file, ready to be flashed.

In Debian, list the mtds:

cat /proc/mtd

===

The other typical way to flash stock FW is to find a stock USB rescue image, and follow the procedure to flash it in serial console.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 12/02/2023 02:51PM by bodhi.