Registered a URL and setup a forum as the IPCam stuff really needed its own site vs my irregular blog posts about IPCam hacking at

Author Topic: NCB541W firmware and webui  (Read 32885 times)

November 16, 2012, 10:42:48 pm
hi, use translator, buy wansview ncb541w and not find firmware files, just find webui file, I want to know if anyone have firmware file and can send it, I want to know if files are compatible wansview Foscam FI8908W ncb541w, this for that DDNS can not change and only have file foscam nO-IP DDNS

  • *****
November 17, 2012, 03:20:23 pm
You do not need to change the firmware to change the DDNS - it is in the settings. Using ANY firmware than that designed for you camera will, most likely, make the camera inoperative. If you insist on changing the firmware, you can (a) email the EansView support and they will email it to you; (b) download the version on this website HERE. WARNING - Do NOT write new firmware without first backing up the existing firmware.

You may be satisfied with changing the DDNS with CGI commands see this website's WIKI and read THIS.
« Last Edit: November 17, 2012, 03:28:06 pm by celem »

  • ***
November 17, 2012, 04:30:43 pm
You do not need to change the firmware to change the DDNS - it is in the settings.

This is not true, in many cases. Foscam, Wansview, other brands and countless camera no-name clones as one example, recently needed to update their camera firmware, for many if not most all their camera models to now support This was due to their prior free DDNS which was included with their cameras, no longer providing/supporting free DDNS services. The firmware readme file, included with the updated firmware, was clear, in many cases, that this was the only reason why the new firmware version was created.

All cameras check the response from the DDNS at startup that support active DDNS interfaces. Because these responses vary from DDNS to DDNS the cameras status pages, may show a DDNS error because the camera cannot properly parse the DDNS response to determine if all is well, at camera startup.

So the camera firmware has a table, based on the DDNS type. However if that type is not defined as a DDNS type, currently supported by the current firmware, that can be selected, then the DDNS response codes will not be in that table to properly query and determine if communications to the DDNS is ok or not ok.

Depending on how the firmware deals with this bad response, it may or may not inform that DDNS of any ISP IP changes. So, just wanted to make this clear.

One does not even need to define a DDNS for the camera and the DDNS will ALWAYS work anyway, if there is/was no ISP IP change, since the DDNS service was originally configured ("Assuming Port Forwarding is setup correctly"). The issue when you do decide to formally define a DDNS for the camera is more about will the DDNS be able to be properly informed of any ISP IP change.

Example: I have 4 DDNS services defined for all my cameras, but only one of them is formally defined in the camera configuration. All 4 DDNS services work, only one of them, however is informed of any ISP IP address changes. The others require manual intervention, to change the ISP IP address, when/if it changes. I have also run the cameras without any formal DDNS configured as well. In that case, all 4 of the DDNS services require manual intervention when an ISP IP address changes.

Since most, if not all cameras, have an Email option to inform you, when/if an ISP IP address changes, this is not a show stopper, because you have methods to determine that the ISP IP address has changed. You just need to update that DDNS service, manually, with the new ISP IP address.

We can use as one DDNS example. When the camera starts it pings the DDNS. In this case, we will use this URL as an example:

See how responds with a "nochg" response? So, when a camera defines a DDNS, it needs to know this proxy URL, to ping at camera startup, as well all possible response code values, in order to determine if the camera is in good communications with the DDNS at camera startup on a DDNS by DDNS basis.

This URL is NOT the URL of the actual DDNS address assigned to you or your camera, it is a DDNS proxy URL used to ping the DDNS, so that the DDNS can update, what it has a your ISP IP address if needed.

Normally, parts of your DDNS address are included in this DDNS proxy URL ping, I am using URL's in these examples to show the concepts. If I were to use real DDNS Proxy address information here, in these examples, I would need to have accounts and user and password information in the examples, so by using these URL's as examples, I can avoid doing that.

We can now use the DDNS URL proxy for, that gets pinged when the camera has it defined as the DDNS, when the camera starts up.

See how this DDNS responds with "NE" as a response.

So, if this proxy URL is not defined correctly and/or the valid response codes are not in a table to parse in the cameras firmware ("Which has no interface to add/update, some cameras do have an interface to update the DDNS proxy URL to update"). Then you will need a firmware upgrade to properly support a specific DDNS. If there is no DDNS type you can assign, that already has those response codes and uses the same communication methods. Since the response codes and sometimes the communication methods used, can and do vary by DDNS.

There are some DDNS services that act the same and have the same response codes, however, you still need to define this DDNS Proxy URL address for the camera to ping at startup so the DDNS service will know what the current ISP IP address is when the camera starts each time, which some cameras do support this DDNS proxy URL to be updated, using developer SDK methods.

I personally know of no camera that supports the response code table AKA DDNS type, to be updated. Which is the cause, in many cases, of why a new firmware release is required, when adding a DDNS, if that DDNS does not have response codes or a type for that DDNS, already defined in the camera firmware.

This is why you will see types, in the cameras DDNS configuration options ("In developer SDK's for cameras"). So, that you can without a firmware change, add a DDNS, if those response codes are already defined or are the same as some other DDNS already defined and the new DDNS interface acts like that DDNS type already defined ("There can also be different communications methods used from 1 DDNS type to another"). Then you can simply use that DDNS type, add your DDNS information and add the DDNS Proxy URL for that DDNS while using that already defined type, response code table, with another DDNS, without the need to require new firmware to do so.

Some links to better show the process, from the DDNS service provider perspective:

« Last Edit: November 19, 2012, 10:21:20 am by TheUberOverLord »