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

Thanks for your answer Fordem!

I have DNS-323 as a print server to Canon MP730, but it goes really slow when I print and the computer nearly hangs because it takes many minutes to contact the printer. When I of misstake have printed two copies of a document I havent been able to access the print queue from the computer to delete the extra print jobs, how can I do it? How can I access the unprinted jobs to delete them?

Ok, I hope D-link fix this bug. But how do I delete the printer spooling directory manually? Where can I find this directory?

Kindly regard, Mikael

Oh no, I noticed it after I sent my message, I read the first bug on the wiki "Printer spooler buffering issue" and was very sure that it were this bug you meant :-). I tried to access the directory \\NAS\Volume_1\.lpd but the folder doesn´t exist, I also looked into this path: \\NAS\lp but no document were waiting. I will try via telnet if I succeed to install the funplug.

Kindly regards, Mikael

Yes, I am not stupid :-) of course I took my own path and I only have on drive installed so the other path doesn´t exist at all.

having same problem but no printer hooked up

Hi leftkidney!

Have you tested to do the same thing as me? When I searched for the problem I came across that it could be that the Daylight Saving Time setting schould be set at None instead of USA or EU. Test this and see if it works.

Kindly regards Mikael

How can you stop what from happening - the DNS-323 from spinning up or the router/computer from sending the arp request?

First - I don't think an arp request will cause the DNS-323 to spin up - I'm too lazy to drag out my laptop and reconfigure my network switch to go snooping, but, Windows will flush a stale MAC address from the arp cache after two minutes, so if I have not accessed my DNS-323 long enough for it to spin down (default 5 mins), it's probably a safe assumption that if it has "spundown", and if I attempt to ping it, the first thing the Windows system will do is issue an arp request in order to get the MAC address it needs.

I can ping the DNS-323 without it spinning up, so it's more than just an arp request that's causing yours to spin up.

As a matter of fact, whilst responding to your post, I have done a lot more than just ping the device, I have pulled up the web admin interface, logged in and checked the power management settings - all without the drives spinning up.  To get the drives to spin up I had to do a directory listing and I was able to spin the two drives up individually, so I'm pretty certain that it takes more than just routine network activity to bring the DNS-323 out of a "sleep mode"

Look closer ....

1 - the arp request is just the first step in the sequence of an attempt to access the device.
2 - there will be no arp request, unless there has been an attempt to access the device.

Last edited by fordem (2008-02-04 19:02:19)

Before we even get to looking at the logs - let's discuss your network configuration because it makes a major difference.

Many small networks are built around unmanaged switches, possibly an integral part of a router, and these switches limit the visibility of network analyzers to the traffic to/from the system they are running on.

The Linksys EZXS55W is a typical workgroup switch - unmanagable and "unconfigurable" - port monitoring is not an option, the WRT54G is also a typical consumer grade router - as shipped by Linksys, port mirroring is not an option and although I could be wrong, I suspect that the ASIC used for the switch function will support mirroring, so even with third party software, it's unlikely that you could capture anything of value with a network analyzer.

If you want to be 100% certain whether the problem is caused by access or not just unplug the ethernet cable to the DNS-323 and leave it disconnected for whatever time period you have configured in the power management settings - if it goes into sleep mode disconnected, but not when connected then external access is what's keeping it awake.

leftkidney wrote:

WTF how does D-Link except people to do this, i mean the reason that they bought this NAS was probably because of storage problems and the NAS feature but where are people sosposta transfer the 500-2000GB that could be in there for a firmware update - just stupid and bad coding IMO

Do D-Link say that? Don't do it if you don't want to, and don't expect any support from D-Link. I didn't take any special precautions when I updated from 1.03 to 1.04b82, and then to the 1.04 (aka 1.04b84), and I didn't have any data loss. But then my data is mostly backups of data stored elsewhere, and I was planning to reformat the drives anyway - your data is probably more important than mine ;-)

I haven't seen anyone report data loss on this forum going from 1.03 to 1.04. You might have to set up users and groups again. Some discussion about if this is needed in this thread http://dns323.kood.org/forum/post.php?t … ;qid=10346. I only have one user in one group (for "private" files), and then "Everyone" access for read only access to one share, and I can't remember if I needed to set it up again or not.

So, take the precautions you think are necessary and then go for it!

leftkidney - Seeing as I have no real interest in third party firmware for the WRT54G, I didn't bother to read past the feature list, all of which appears to be router functionality, with a few wireless features - nothing switch related is mentioned - and nothing to change my opinion that there is a single switch ASIC in the device.

Sure it now has enterprise router features, but does it have enterprise switch features - I don't think so, and I don't think adding those features is as simple as a firmware upgrade - I could be wrong but I don't think the silicon supports it.

In short - looking at wireshark logs is not likely to produce anything of significant value.  This is probably a moot point since you already know that the device will spin backup even when disconnected, indicating that the spinup is caused be something internal.  You now need to start looking at what you're doing with the device - there are many documented instances where some added functionality needs to write to a log or similar that causes the spinup.

With regard the firmware flash and the backup - strictly speaking it's not required, assuming you're already running ext2 - it is however good practise and DLink points this out in RED on the support webpage, directly above the list of available firmware.  I have noticed that it seems to be only in the consumer end of things that I see the sort of arguement that you present - where are you supposed to transfer the data before a firmware update?

This is not about bad coding - the best coders in the world can't prevent a glitch from occuring during a firmware flash.  It's about common sense - why should you need to transfer the data anywhere - if it's of any value you should already have it backed up elsewhere.

@left kidney - perhaps you have a defective unit - mine certainly doesn't run all the time and never gets more than barely warm even when in use.

Either that or you don't understand my questions - in another thread you just posted that you have no hacks, yet here you are saying you have modded the unit so the fan stays on all the time.  Whether you rewired the fan or run fun_plug and some sort of fan control script, it's a hack - and some of the stuff that's been done through fun_plug does keep the drives active.

Maybe you just want to vent your frustrations at the device, that's your perogative, but it would be a waste of my time to try to assist you in any way, if you're not going to provide the details I ask for.

I has suggested you start a new thread - I'm going to add to that - if you're serious about making this thing work, use the web interface to save the config and then reset it to factory defaults and remove any fun_plug or similar - if you have a spare disk, install that and format a single volume - if it power management does not work like that, it's defective and should be RMA'd if it's under warranty.

On the other hand - if it does work correctly that way - reinstall your disks, restore your config and open a new thread - and lets take it from there.