Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Cliff]

Can't seem to narrow down all the circumstances, but sometimes the NAS just stops responding. The webpage responds, but nothing else. Can't see any of the folders/files, the iTunes and FTP server all don't respond.

I can physically reset the box, but I really wish that wasn't necesary.

[Cliff]

I downgraded the firmware to 1.04, but same result. This morning the box is non-responsive. Status page shows temperature of 46. I can save a setting on the webpage, but nothing else responds.

[ECF]

Try disabling any unused feature like UPnP AV media server, Itunes server, or FTP server. see if that helps. If you are using the UPnP AV media server or iTunes server try selecting a folder containing your media you would like to share as opposed to the root.

[ocular]

I get this problem (using 1.04) on an unpredictable basis -where  can't get network access to DNS 323, web access via IP works. The DNS 323 just cannot be seen from any of the workstations on the network.

So what I do is go to the web configuration Advanced/Network Access/ Network Access List and click on the modify setting button and then click apply.

Why does this happen. Is the latest FW fixing this?

[hilaireg]

Do you have Jumbo Frames enabled on the DNS and/or the remainder of your network?

[fordem]

Do you have Jumbo Frames enabled on the DNS and/or the remainder of your network?

I'm not going to say that jumbo frame is not the cause of the problem, but rather that jumbo frame should not cause a problem.

From a wireless-g equipped laptop associated with a Netgear 802.11n router cabled to a Netgear smart switch at 100 mbps, across to a second Netgear switch via a dual link gigabit LAG and then to the DNS-323 at 1000 mbps, I get the following ...

jf enabled (9000 byte) - 1.99 MB/sec write, 1.43MB/sec read
jf disabled - 1.92MB/sec write, 1.82MB/sec read.

Before anyone misunderstands the post and points out that jumbo frame does not run over wireless - I am well aware of that, the point is to show that it is possible to have jumbo frame enabled at one end only.

I have been running a network with partial support for jumbo frame for almost four months with daily access to the DNS-323 from gigabit clients (both with & without jf) as well as 100 mbps and wireless without a single freeze or lock up.

[hilaireg]

Fair enough,

However, in order to determine the possible source of the problem, still need more information - such as:

- Is JF currently enabled
- Are all workstations & DNS members of the same WORKGROUP
- What type of switch is being used and does it support JF
- Are the LAN cables purchased of home-made and what CAT are they as well as what standard 568A/B

Once the information is supplied, it may be possible to provide some hints as to why it's locking up.  Part of the troubleshooting effort would involve getting to a simple configuration and building from there until the problem manifests itself.

... the standard tech support stuff 

Cheers,

[fordem]

Not arguing, but, based on my experience (accumulated over 30+ years ), none of the items listed should cause a freeze or lockup - at least under my understanding of the term - let's take a look at them one by one.

I'll deal with "Is JF currently enabled" & "What type of switch is being used and does it support JF" together, since they are related

As explained in the post above, JF being enabled at one end of the connection does not cause a problem and has a negligable impact on throughput - however - if JF is enabled on both ends AND the switch(es) linking the two does not support JF, there will be large numbers of dropped packets - however this will affect both http and SMB and is readily apparent in the time taken to bring up the web admin page.

Are all workstations & DNS members of the same WORKGROUP

Again - not a cause for a lockup - this would/should cause problems initially locating the drives, but once the drive has been found and attached, it should cause no further problems, and the drive should be available by it's ip address at all times (//<ip-address-of-DNS-323/Volume_1).

It should be noted that Windows search can be used to find computers or other resources when the only thing that is known is the NetBIOS name - it will search across workgroups and will even find systems in the same workgroup that are not visible in My Network Places due to the various quirks of the master browser mechanism.

Are the LAN cables purchased of (or?) home-made and what CAT are they as well as what standard 568A/B

In most cases bad cabling will not manifest itself as a lockup or freeze requiring the device to be reset - a defective cable that allows communication will typically cause either reduced throughput - or - will cause a file transfer to fail under certain circumstances, typically small files transfer and larger files result in the connection dropping temporarily - it's been my experience that after the connection drops you can immediately reconnect and just as an example, browse the directory contents and transfer small files.

Home-made cables can cause these problems if they have been miswired - split pairs are fairly common when done by someone lacking experience, however, whether or not this causes problems is dependent on the length of the cable and perhaps how "electrically noisy" the environment is, but, typically it will not cause a lockup (see paragraph above).

What CAT - again - depends on the length and the environment - I doubt that you'll find anything less than CAT5 in the average network now and CAT5 is adequate.

TIA568A/B - irrelevant - either standard can be used as long as it is followed on both ends of the length of cable (if not a crossover cable results), yes, I am aware of the fact that it is recommended that one standard, either standard be used throughout an installation, and that switching from 568A to 568B, in a single run - for example the fixed cabling being one standard and the patch cords the other - can theoretically cause skew, you'd have to be pushing the installations to it's limits to see the results of that.

I do agree with the simplify the configuration and build from there.

Start by disconnecting the DNS-323 from the network and leaving it disconnected long enough for the freeze or lock to occur and then reconnect and see if it is accessible - the idea here is to determine if the cause is internal or external - if it's internal, reset the unit to factory defaults and reconfigure.

I'd like to suggest that you NOT save the configuration and restore it after the reset, it is possible to get a corrupt configuration file which can cause other issues (usually the web interface crashes and the shares remain available, but a complete crash of the system is not unknown).

[hilaireg]

I'll deal with "Is JF currently enabled" & "What type of switch is being used and does it support JF" together, since they are related

As explained in the post above, JF being enabled at one end of the connection does not cause a problem and has a negligable impact on throughput - however - if JF is enabled on both ends AND the switch(es) linking the two does not support JF, there will be large numbers of dropped packets - however this will affect both http and SMB and is readily apparent in the time taken to bring up the web admin page.

The dropped packets will be more apparent in SMB and not as apparent in HTTP traffic as the protocols handle error correction differently.  That said, the poster was not clear if problems were encountered while navigating the HTTP pages on the DNS.

Lastly, implementation of JF technology is vendor-specific which implies that not all JF-capable devices will 'play nicely' ... I've seen this first hand with some recent tests with Broadcom NIC's using their latest drivers on a WinXP Pro workstation.

Are all workstations & DNS members of the same WORKGROUP

Again - not a cause for a lockup - this would/should cause problems initially locating the drives, but once the drive has been found and attached, it should cause no further problems, and the drive should be available by it's ip address at all times (//<ip-address-of-DNS-323/Volume_1).

It should be noted that Windows search can be used to find computers or other resources when the only thing that is known is the NetBIOS name - it will search across workgroups and will even find systems in the same workgroup that are not visible in My Network Places due to the various quirks of the master browser mechanism.

Agreed, it is not the cause of the lockup but the poster also indicated that the DNS was not visible to the workstations - a separate problem.  It's possible that the DNS is in a different WORKGROUP making it invisible to NetBIOS but reachable by IP.  Once again, the poster was not clear about the configuration of the DNS 'WORKGROUP' name and the Operating Systems in use - WinXP Pro, WinXP Home, Vista, etc.

As for Windows Search (the non-puppy version), I seem to recall it does both NetBIOS and DNS indexing.

Are the LAN cables purchased of (or?) home-made and what CAT are they as well as what standard 568A/B

In most cases bad cabling will not manifest itself as a lockup or freeze requiring the device to be reset - a defective cable that allows communication will typically cause either reduced throughput - or - will cause a file transfer to fail under certain circumstances, typically small files transfer and larger files result in the connection dropping temporarily - it's been my experience that after the connection drops you can immediately reconnect and just as an example, browse the directory contents and transfer small files.

Home-made cables can cause these problems if they have been miswired - split pairs are fairly common when done by someone lacking experience, however, whether or not this causes problems is dependent on the length of the cable and perhaps how "electrically noisy" the environment is, but, typically it will not cause a lockup (see paragraph above).

Agreed, my point exactly.  If bad cabling is involved, then the communication to the network devices on the LAN will be questionable.  In my 30+ years in this business, I've seen a fair number of issues that were related directly to faulty cabling and network devices.  Enough packet malformations can cause a device to lockup/reset - the WinXP event log displays TCP/IP stack resets. 

As a general rule, an end-to-end verification should always be performed when it comes to networking.  And based on your posts, I'm quite certain you've run into unpredictable issues that were related to firmware deficiencies on a network device, bad punch downs on blocks, and minor cable fractures that pass cable tests.

That said, the poster hasn't provided enough details about the construction of the LAN and therefore the assumption is that the DNS is at fault - which it might be - but that can't be confirmed until more detail is provided about the environment.

What CAT - again - depends on the length and the environment - I doubt that you'll find anything less than CAT5 in the average network now and CAT5 is adequate.

TIA568A/B - irrelevant - either standard can be used as long as it is followed on both ends of the length of cable (if not a crossover cable results), yes, I am aware of the fact that it is recommended that one standard, either standard be used throughout an installation, and that switching from 568A to 568B, in a single run - for example the fixed cabling being one standard and the patch cords the other - can theoretically cause skew, you'd have to be pushing the installations to it's limits to see the results of that.

Problem is we don't have enough information to provide some guidance.  Most forum members will be happy to help provide a solution if sufficient details are provided to begin with.  There's nothing more irritating than finding out the reason for the problem is that the power isn't on in the neighborhood

I do agree with the simplify the configuration and build from there.

Start by disconnecting the DNS-323 from the network and leaving it disconnected long enough for the freeze or lock to occur and then reconnect and see if it is accessible - the idea here is to determine if the cause is internal or external - if it's internal, reset the unit to factory defaults and reconfigure.

I'd like to suggest that you NOT save the configuration and restore it after the reset, it is possible to get a corrupt configuration file which can cause other issues (usually the web interface crashes and the shares remain available, but a complete crash of the system is not unknown).

Disconnecting and reconnecting the device will only confirm that the device itself is not faulty if the Web Interface can be contacted once an IP has been received by the DNS.

Again, the poster hasn't provided enough details as to what's been attempted and when the DNS appears to lockup (i.e. Heavy I/O, specific time of day, etc.)  I myself would be interested in knowing what HDD's are in the unit & f/w versions and if the DNS has actually been factory reset before 'ocular's'  post was submitted.

Typically, I create a configuration document for all devices that I work with.  As I update the device firmware or change settings, I note the changes in the document.  The document provides a manual reconfiguration method should a device factory reset be required and/or the configuration file is incompatible between versions.

Cheers,

[mcgyver75]

Hi all ... i have a same problem ... i filled up my dns 323 with quite all music found in my old cd/dvd. Now, when i try to activate itunes server, web serfver of dns323 stop responding. HD led activity start, light is not blue but quite orange and dns-323 stop responding. Connecting after 2-3 minutes will made available web services, but not shared folder? my firmware is 1.06, but with 1.04 and 1.05 issue are the same. any help? thank you very much. :-|