DSM-G600, DNS-3xx and NSA-220 Hack Forum

Bad idea to mess with the backup file, especially if you have telnet access.  Search the forum for how many people have bricked their unit attempting this.  There are much easier ways of making modifications without risking the unit.  Also, there is a big warning on the Wiki (I know you are sure you did not make the crlf mistake), and if you noticed, the Wiki talks about changing share names from Volume_1 to another name, NOT swapping Volume_1 and Volume_2.  It goes on to mention that those are embedded in the binaries.  Anyway, about your problem:

You most likely had 1 drive in the left hand bay and added the second to the right hand bay.  This explains what the Volume names were different than what you expected.  Notice how I did not say mismatched or wrong.  This is actually correct and expected.  Slot 0 is actually on the right bay and slot 1 is on the left bay.  By default, slot 0 is seen first, hence HD_a2, but since it was the second drive added to the unit, it was assigned share Volume_2.  Slot 1 is now HD_b2, but it is still assigned to Volume_1 since it was the original drive.  To fix the share name issue you had, just swap the drives.  This is the most common cause of this scenario.

Since you have telnet access, you are one step up.  Telnet in and run

ps

See if /web/webs is running.  If it is not, start it by running

/web/webs &

If it is already running, kill it, then start it again with the command above.
You should get something that looks like this:

/ # /web/webs
Quota Start
Set Daylight :/usr/sbin/daylight 1 &
country = 31
Daylight mode : USA
StartDaylight US = March 9
EndDaylight US = November 2
US new daylight saving time
rm: cannot remove '/tmp/set_ddns_done': No such file or directory
rm: cannot remove '/tmp/set_ddns_error': No such file or directory
rm: cannot remove '/web/ddns_start': No such file or directory
language=1

You will also notice that your prompt will not return right away, this is expected.  You can still run commands in the telnet session as webs in running in the backround.  Now, leave the telnet session open and try to access the web admin tool.  Also note that as you access the web admin tool, you should get feedback in the telnet winndow.  If it works, upload the original configuration backup file.  You did save an unmodified copy, didn't you?

If this did not work, try doing the factory reset.  http://dns323.kood.org/howto:hardware_reset
Keep in mind this may not work, in which case you need to talk to the guys in the custom firmware about how to recover from a brick.  They use kermit to manualy upload the original F/W to flash.

Last edited by bq041 (2008-08-24 11:34:20)

The ^M is the Linux notation for CR (CRLF issue).  Here is what mine looks like:

/web # cat ddns.conf
CF-DDNS-ENABLE = "0"
CF-DDNS-USERNAME = ""
CF-DDNS-PASSWORD = ""
CF-DDNS-DOMAIN = ""
CF-DDNS-SERVER = ""
CF-DDNS-TIMEOUT = "2073600"
/web #

I do not use DDNS on my box, hence the 0.

Also check the file shared_name, and all the .conf files for this.  Use vi to remove any ^M in any of the other files.  Once you can get /web/webs up and running again, the load the original back-up file in, or (this may actually be better) load in stcok DNS firmware to reset everything back.

I'm attaching my ddns.conf file for you.  This you can copy onto the right location and use chmod to set it to 755 (it is 777 so you can work with it).

---

Attachments:
ddns.conf, Size: 133 bytes, Downloads: 346

jalin2 wrote:

However, it doesn't come up on reboot even after I reloaded firmware (v1.05).

Take a look at: http://dns323.kood.org/forum/p13670-200 … tml#p13670

Thanks mig for the link.  I followed the suggestion of toggling the ddns page settings and it's all fixed now.

Thanks bq041 for your help also.  It's all good.