Print

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

[weilun106]

Hello first post here for a bizzare question.

I got my DNS-323 all set up few days ago, everything seems fine. Firmware is 1.06 and BT function was intalled. Everything works perfectly under my Windows XP Netgear wireless router. After i got home this evening, the download screen shows connecton failed. This happened a couple times before and everything start working after reboot. However this time NAS simply disappear from my local network. I can't find it by using easy search utility. This has never happen before, I didnt change any setting. It just lost and can't be detceted anymore.

The strange thing is I can still access NAS to browse and edit files I store in it through a short cut I made before the NAS disappear. But the IP f the NAS 192.168.1.3 just not showed on my easy search utility 4.4.0.0. Can anyone help me solve the problem? If I can't log in to the NAS' control kernal, I can do nothing with it. Now it's just like a enclosure on my local network.

Thank you guys sooo much!

 

[gunrunnerjohn]

Are you SURE it's still at that IP address?

[weilun106]

Yes I'm pretty sure the IP address is the same, because the shortcut still works. I can still access DNS-323 and use it like a hardrive enclosure on local network. However nothing was shown on easy search utility. Has anyone experience this problem? HELP ME Thanks!

[gunrunnerjohn]

Look at the properties of the shortcut, mine don't have the IP address as part of the path.  Here's what my shortcut to my DNS-323 looks like.

\\DNS-323\Volume_1

Even if the IP address changed, this would still get to it.  Ping the name and see what IP address it returns.  For instance, when I ping mine by name.

Pinging dns-323 [192.168.0.143] with 32 bytes of data:

[weilun106]

this is the result of pinging

C:\Documents and Settings\Wayne>ping 192.168.1.3

Pinging 192.168.1.3 with 32 bytes of data:

Reply from 192.168.1.3: bytes=32 time=51ms TTL=64
Reply from 192.168.1.3: bytes=32 time=1ms TTL=64
Reply from 192.168.1.3: bytes=32 time=2ms TTL=64
Reply from 192.168.1.3: bytes=32 time=10ms TTL=64

Ping statistics for 192.168.1.3:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 51ms, Average = 16ms

IP address is the same, still can access the hardrive. But cant open the login page of NAS control panel nor finding the device through easy search utility Anyone knows what can I do now?

[gunrunnerjohn]

One has to wonder why the ping times are all over the map on a local network, what's up with that?  On a local network I'd expect MUCH shorter ping times.  This is more along the lines of what I'd expect, here's mine.

C:\Users\John Will>ping dns-323

Pinging dns-323 [192.168.0.143] with 32 bytes of data:
Reply from 192.168.0.143: bytes=32 time<1ms TTL=64
Reply from 192.168.0.143: bytes=32 time<1ms TTL=64
Reply from 192.168.0.143: bytes=32 time<1ms TTL=64
Reply from 192.168.0.143: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.143:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

[Rodent]

Here's mine

ping dns323

Pinging dns323 [xxx.xxx.xxx.xxx] with 32 bytes of data:

Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64
Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64
Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64
Reply from xxx.xxx.xxx.xxx: bytes=32 time<1ms TTL=64

Ping statistics for xxx.xxx.xxx.xxx:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

[fordem]

One has to wonder why the ping times are all over the map on a local network, what's up with that?  On a local network I'd expect MUCH shorter ping times.  This is more along the lines of what I'd expect, here's mine.

Off topic, but, since you're wondering ...

Ping was intended to verify communication, so the fact that you get a response is what's important, rather than perhaps the "response time".

I don't know if you have ever seen situations where you can ping a server and consistently get <1 mS response times, but if you ping the network switch to which that server is connected (and through which your ping request must pass, both the request and the response) and the ping times from the switch are longer than 1 mS.  Of course this is only possible if you're using a managed switch.

Now - think about this carefully - let's say you have a hundred feet of CAT6 cable between your computer and the switch, and another hundred feet of CAT6 cable between the switch and the server, so when you ping the switch it takes x mS to respond, you'd think it would take 2x mS to get a response when you ping the server - after all twice the cable, twice the time - but in reality the ping response from the server is consistently <1 mS.

The actual cause of the phenomenon is quite simple - responding to a ping request is a secondary function and is treated with a lower priority, so if your router or switch is busy doing what it's designed to do, routing or switching, that's where it will focus, and when it has a few CPU cycles to spare, it'll respond to your ping request - your server on the other hand probably has more than enough processing power and can get to your ping request with a little more alacrity than the flea powered embedded processor in the router or switch.

In short - without knowing how busy a given network or device is - using ping to determine anything more than basic connectivity may well be an exercise in futility.

To go back to the original poster's question - I believe there is a known problem with bt that can cause the webserver to become inaccessible

[gunrunnerjohn]

Off topic, but, since you're wondering ...

Ping was intended to verify communication, so the fact that you get a response is what's important, rather than perhaps the "response time".

I don't know if you have ever seen situations where you can ping a server and consistently get <1 mS response times, but if you ping the network switch to which that server is connected (and through which your ping request must pass, both the request and the response) and the ping times from the switch are longer than 1 mS.  Of course this is only possible if you're using a managed switch.

Now - think about this carefully - let's say you have a hundred feet of CAT6 cable between your computer and the switch, and another hundred feet of CAT6 cable between the switch and the server, so when you ping the switch it takes x mS to respond, you'd think it would take 2x mS to get a response when you ping the server - after all twice the cable, twice the time - but in reality the ping response from the server is consistently <1 mS.

The actual cause of the phenomenon is quite simple - responding to a ping request is a secondary function and is treated with a lower priority, so if your router or switch is busy doing what it's designed to do, routing or switching, that's where it will focus, and when it has a few CPU cycles to spare, it'll respond to your ping request - your server on the other hand probably has more than enough processing power and can get to your ping request with a little more alacrity than the flea powered embedded processor in the router or switch.

In short - without knowing how busy a given network or device is - using ping to determine anything more than basic connectivity may well be an exercise in futility.

To go back to the original poster's question - I believe there is a known problem with bt that can cause the webserver to become inaccessible

What can I say, other than you're wrong.  On a simple home network with a router and a few workstations, you should never see ping times even approaching what he sees.  I actually know quite well what Ping is supposed to accomplish. 

The bottom line is, ping times of 50ms on a hard wired home network are NOT normal and could be a symptom of what is going wrong here.  It also could be something totally unrelated.

Debugging is simply the process of observing the symptoms and verifying the cause of any unusual symptom that could impact the issue.  Clearly, this kind of response on the network indicates some unusual happenings.  Even if it's not the cause of this issue, it will certainly impact his network speed.  Maybe it's just other heavy traffic, maybe it's not.

Dragging a corporate network in with managed switches and routers is hardly useful in analyzing this issue on this network.

[fordem]

What can I say ...

other than I was expecting a response of this nature from you.

First - I don't see him describing his network anywhere, so you're making some assumptions there - it may or may not be a simple router based home network.

Second - the network described is not a big corporate network, but in fact, a SOHO one with no more than four users - so what if I chose to pay more for a switch with management capabilities - and by the way, it's actually a "smart switch" rather than a fully managed one, and surprisingly affordable.

The point that you apparently failed to grasp is that ping response times are not a true indicator of network latency, because they also include the time that the device itself takes to respond.

I did go to some length to explain that lower powered devices may take longer to respond, but I guess you didn't see the connection - so let me make it clear - inside the DNS-323 is a 500MHz Marvell Feroceon (ARM) processor with 64Mb RAM.

In the original post we see that the OP has installed and is using bt, which is the reason that I mentioned that there was a known problem with bt causing the webserver to become inaccessible - I now put it to you, that the processor load cause by the bt application not only causes the webserver to become unresponsive, but also cause the DNS-323 to not respond to a ping request in a timely fashion, resulting in the apparent latency which puzzles you.

So - like I said earlier - without knowing how busy a given network or device is ...

[gunrunnerjohn]

You seem to assume facts not in evidence.  I've worked on a ton of networks, and been involved in several support forums for years doing network support.  What you describe is NOT normal for any home network, even with a smart switch.  The only scenario where you might get a measurable delay is a very sick machine or switch, or very heavy traffic.

You're making as many, or more assumptions than I am.  Playing the odds, I would expect the DNS-321 or DNS-323 to respond to a ping within 100's of microseconds, and one of each model does indeed for me.

Just to see if it makes a difference, I started a large file transfer from both the DNS-321 and DNS-323 and then tried pinging them while the transfer was taking place.

Bottom line, the transfers made no difference in the ping times.  I tried it both reading and writing to the units, same results.

Maybe you should just fix your network if you get different results.


Pinging dlink [192.168.0.142] with 32 bytes of data:
Reply from 192.168.0.142: bytes=32 time<1ms TTL=64
Reply from 192.168.0.142: bytes=32 time<1ms TTL=64
Reply from 192.168.0.142: bytes=32 time<1ms TTL=64
Reply from 192.168.0.142: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.142:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\John Will>ping dns-321

Pinging dns-321 [192.168.0.143] with 32 bytes of data:
Reply from 192.168.0.143: bytes=32 time<1ms TTL=64
Reply from 192.168.0.143: bytes=32 time<1ms TTL=64
Reply from 192.168.0.143: bytes=32 time<1ms TTL=64
Reply from 192.168.0.143: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.143:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

[fordem]

Again - you seem fixated on the network itself - you seem not to notice that I speak of CPU loading.  Try running bt or another application on the DNS-323 and then ping it.

I won't comment on your "ton of networks" other than to say - I probably have as much experience if not more given the fact that I have spent more than three decades doing what I'm doing and have been sufficently successful that I can now run my own consultancy business doing it.

[gunrunnerjohn]

Let's agree to disagree here, neither of us appears likely to change the other person's viewpoint. 

[ECF]

Hello first post here for a bizzare question.

I got my DNS-323 all set up few days ago, everything seems fine. Firmware is 1.06 and BT function was intalled. Everything works perfectly under my Windows XP Netgear wireless router. After i got home this evening, the download screen shows connecton failed. This happened a couple times before and everything start working after reboot. However this time NAS simply disappear from my local network. I can't find it by using easy search utility. This has never happen before, I didnt change any setting. It just lost and can't be detceted anymore.

The strange thing is I can still access NAS to browse and edit files I store in it through a short cut I made before the NAS disappear. But the IP f the NAS 192.168.1.3 just not showed on my easy search utility 4.4.0.0. Can anyone help me solve the problem? If I can't log in to the NAS' control kernal, I can do nothing with it. Now it's just like a enclosure on my local network.

Thank you guys sooo much!

 

Does it come back after a restart? Are you leaving the unit logged into the BT downloader and leaving when this happens?

[amunoz_tico]

Does it come back after a restart? Are you leaving the unit logged into the BT downloader and leaving when this happens?

How can a user install or upgrade to a new firmware version if the web page is not working?  Can he move the file to root and run a command?