Print

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

[dgez]

I have posted my issue on many of forum on the internet and spoke with DLINK support many of times.  No one can help me.  Since this is a new forum, I will repost my story.  It pains me to speak about it, much like talking about a tragic event that happened in the past.  I'm sorry for the length, but it needs to be long to understand the full picture.

I bought a DCS-5300G 3.5 years ago to use as a baby monitor.  At the time, I had a kid on the way, and a DI-524 router.  The camera, for the most part worked fine, locally and remotely.  I moved to a bigger house and felt I needed a bigger router, so I bought a DGL-4300(rev2 I believe, 1.6 firmware).  Hooked everything up.  The camera worked flawlessly locally and remotely.  The kid came, and I was off work for a month.  During this time 1.7 firmware was released for the DGL-4300 and I upgraded.  The camera worked fine locally, since I was not at work I could not test remotely.  After a month off I went back to work, I started to have trouble with the camera when accessing over the internet, It would connect and work one time, but if refreshed the page I would get 'page cannot be displayed'.  When this occurred, you would get the same 'page cannot be displayed' locally as well.  The camera was still pingable, not just accessable over its web interface.  The fix was to power cycle the camera or reset the camera via telnet.  This problem was only triggered when accessing the camera remote.  Accessing locally never caused this issue.

For weeks I troubleshooted, verified the correct ports were open on the router, changed the camera to the DMZ, reflashed firmware, tried wired and wireless and played with every setting in the router and camera.  Finally fed up, I called DLINK.  After a painstaking conversation about basic troubleshooting that I had already done, or had nothing to do with my problem, I was escalated to a differnet level, and they eventually granted me an RMA for the camera.

I got a RevB camera as a replacement.  Hooked it up, configured, tested at work, same problem.  OK, so its not a camera problem, must be the router.  After thinking about what I had changed, the firmware upgrade I had done on the DGL-4300 over a month ago hit me.  I back flashed the router to 1.6 and BOOM! it worked again.  I did some further troubleshooting at 1.7, I noticed that 1.7 enabled NAT endpoint filtering.  I messed with every setting for this and it did not make a difference. Eventually said screw it and left the router at 1.6.  I also purchased a DCS-6620G at this time and it worked great as well.  My home network was happy, I was happy...so I left it alone. 

Then some divine intervention happened.  Just about 1 year ago we had a bad thunderstorm.  Lightning hit near by and I suffered some casualties.  My cable modem, DGL-4300, and the NIC that was hardwired to the DGL-4300 got completely fried.  Modem was replaced by comcast, went to best buy and bout a new NIC and a DIR-655.  Hooked everything up.  Locally everything was fine, but accessing the DCS-5300G remotely caused the same problem.  The DCS-6620G worked great.  Back to the drawing board...

I went back to best buy and tried a DIR 855.  Same freakin' problem.  All of these routers have NAT endpoint filering.  I decided to buy a DGL-4300 online because I knew that router worked.  But the DGL-4300 I got was a REV4 and came with 1.7 firmware on it, which of course had the same problem.  I back flashed this REV4 DGL-4300 to 1.6 and it pretty much made the router non functional.  So, I flashed the DGL-4300 back to a working level of 1.7, picked up the phone and called DLINK.  This time I was armed with network traces showing that when in a failing state and when a computer tried to connect to port 80 on the camera, the camera would respond with a RST/ACK which means th port is closed.  THIS IS OBVIOUSLY A PROBLEM!  The DLINK support rep failed to comprehend anything I was saying and instead said there are no known issues like that.  I gave up on DLINK and bought a Belkin N router and everything is functional. 

My observations from this whole ordeal:  DLINK support is worthless, and any DLINK router that has a NAT endpoint filtering as an option does not play nice with a DCS-5300G.  Since the problem only occurs when accessing the camera through the routers NAT I would think that this is the bulk of the issue, but I do not know this for certain because DLINK refuses to acknowledge, let alone fix, this issue.

Your thoughts are welcome. 

[ECF]

Did you ever see this problem with the DCS-6620G? What firmware was used on the DCS-5300G revB?

[Fatman]

Given what you have posted I am more interested in the capture that crashes the web server on the DCS, not what it does once it is crashed.

You have identified NAT endpoint filtering as the culprit, can you show the mechanism of this feature crashing the web server on the DCS?

[dgez]

ECF, The problem never occured with the DCS-6620G.  Firmware 2.02 and 2.03 were tried on the RevB DCS-5300G.  I see there is a 2.05 out now which I have not tested.

Fatman,  I will give you a little more detail on whats happening.  When accessing the camera remotely it would always open and work the first time.  If I opened another browser ( or just refreshed the page)  and connected to the camera, it would usually fail and I would get a page cannot be displayed.  Local access at this time did not work either, yet I am still viewing and controlling the camera on my original browser.  So its like the cameras web server is refusing new requests.  If I were to refresh my working browser or click on one of the camera config options, I would get page cannot be displayed.  So the cature shows that the camera all of a sudden starts sending RST/ACKs when a computer tries to connect to its web server port, 80 or whatever change it to.

I cannot prove that Nat endpoint filtering is the culprit, I am not even sure its the cause.  But its the only common demoninator between these DLINK routers.

[Fatman]

So the problem only occurs when you already have a connection open, now that is something more that we can work with.

I am just letting gums fly here but....  Perhaps an interaction of NAT endpoint filtering hanging an opening connection on that socket on the DCS is preventing new connections till that socket times out?

Lets get this straight, this only happens if you open the cameras page multiple times from the same remote endpoint?  Then as the old joke goes, don't do that, there is no utility in it.

This makes my original question, do you have any captures of this entire process?  The working connection and the failed ones?

Does the problem resolve itself after a set period of time?  If so how many seconds?

I would be careful about the phrase only common denominator, rather I would say only known common denominator.

[dgez]

It doesnt just happen when opening multiple connections from one endpoint, it will also happen with just one connection.  If I have the camera up and its working and I want to go to the config options, it will eventually fail as I am navigating around the menus.  I suppose this still could be considered multiple connections since an existing connection is requesting access to different directories...

I did have captures of the entire process, but I do not have them anymore.  They did not show anything obvious other than all of a sudden the camera was sending out rst/acks instead of syn/acks.  Here is the jist of the traces

Computer sends SYN to the Camera.
Camera sends a SYN/ACK.
Computer sends ACK to camera
This conversation repeats while working
Refresh web browser
Computer sends SYN to the Camera
Camera sends a RST/ACK
Refresh web browser
Computer sends SYN to the Camera
Camera sends a RST/ACK
Must reset camera

The problem never resolves itself.  The camera has to be reset.  Though I never waited more than a couple of hours.  Apparently firmware 2.03 and below has a watchdog that reboots the camera every 24hours, I suppose if I waited for the magical 24hour mark when it auto resets, it may fix it.

This brings me to an unrelated issue/question.  If I remove power from the camera by pulling the ac adapter from the wall outlet and leaving in plug in the back of the camera, when I replug it I lose PTZ control of the camera, the video feed is fine.  This also occurs if there is a power outage, since that pretty much simulates pulling the adapter from the wall and not the camera.  Soft resets through the web browser or telnet do not fix it.  It seems the only way to properly reset the camera is to pull the cable from the back of the camera and not the wall.  Is this normal?

[dgez]

One other piece of info that I had was a debug file from the telnet interface of the camera before during and after the crash.  I begged the DLINK support rep to have someone analyze it, but he didn't even know who to go to with it.  I think this issue needs to be debugged from within the camera and not from external network traces.

[Fatman]

Thing of it is, to my knowledge we only have this one report, and only under fairly specific but clearly not exacting circumstances.

This tells me that it is most likely we are experiancing a failing system not a failing device

Debugs (usually, I don't know about this device) stop time and present a memory map as of that point in time, not only is it costly time wise to analyse such information, it only helps if the failure is isolated to a specific process being inspected in that device and in memory at that moment.  Often the bug isn't a failure at these lowest levels but a collection failure amongst multiple processes in the device or devices within their respective system.

Much to the dismay of my CS professors I am going to have to offer a quote for the issue here.  "A process cannot be understood by stopping it.  Understanding must move with the flow of the process, must join it and flow with it".

Since what we can gleam from inside the device is narrow, an external inspection to the device which is yet an internal inspection of the system is the best path available. 

This will show the mechanism of failure and it's symptoms, I began with captures since you mentioned having already taken them, I now see that was my failure.

[dgez]

Here is what I will do.  Since I do not want use the DGL-4300 as my active home router, I will set up a simple test.  I will set up one of my PC's to be a DHCP server (to emulate my ISP and WAN side client) and plug it into the WAN port of the DGL-4300.  I will then hardwire the DCS-5300G to the router and access the camera through the routers NAT.  I will take wireshark traces of the session.  This test will take my ISP out of the picture, which I have not previously done before...I can't imagine it would be an ISP issue though since 1.6 firmware on the DGL-4300 works and other non DLINK routers work.  This may take me a few days to get around to doing.

Also, if needed and if you are willing, I will hook everything up and give you full access to the router and the camera, and you can poke around and see what you can find out.  If you are willing to do that, I am certainly willing.

[Fatman]

For right now the Wireshark in that environment is sufficient to get some traction.

Taking the ISP out of the picture is a great idea, I didn't know you had the option and willingness to go there or I would have suggested it myself.  truthfully you don't even need the router just give your PC on the WAN port a static IP and assign one on the DMZ in the same network with your PC as it's gateway.

I may poke around later but for now a capture of the failure will at least give me traction for my own testing, which is crucial.

If you could take one capture form inside the LAN and one from your WAN this would be a great boon.

[dgez]

It probably wont be until early next week until I get this all setup.

I will get a bunch of data together and post the results.  Thanks!

[Fatman]

Merci!

[dgez]

I did some more testing.  It appears if I take my ISPand modem out of the picture, the issue does not occur.  Here is what I know so far

Comcast -> SB5120 -> DGL-4300 (fw 1.6) ->DCS-5300G.  WORKS
Comcast -> SB5120 -> DGL-4300 (fw 1.7 or higher) ->DCS-5300G.  FAILS
Laptop -> WAN port of DGL-4300 (any firmware) -> DCS-5300G.  WORKS
Comcast -> SB5120 -> Belkin N -> DCS-5300G.  WORKS

I find it hard to believe that Comcast may be responsible for this.  I mean the camera is crashing and its inacessable even from LAN. 

I have the DGL-4300 hooked back up.  Its currently at 1.8 firmware.  The camera crashes like I expected.  I took three traces.  One from a remote computer before, durning and after the crash.  Another at the same time on a LAN computer before, during, and after.  And one more on a LAN computer after the crash. 

Is there any specific trace you would like me to capture?  How can I get them to you?

[Fatman]

I find it hard to believe that Comcast may be responsible for this.  I mean the camera is crashing and its inacessable even from LAN.

As I have been trying to explain, I highly doubt anything is solely responsible for this issue.  This appears to be a failure involving a fairly complex set of interactions between multiple devices.

I will PM you an FTP server you can upload them to, just PM me the file name(s).

[starx]

I was having the identical problem and I read your post hoping for some help.
I saw that you also connect via Comcast so I double checked my router settings and noticed that they had changed their DNS entries.

I updated the DNS settings on the camera and now it seems to be working perfectly - go figure.

You may want to check this if you are still using this camera.