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 no-ip.com. 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 no-ip.com as one DDNS example. When the camera starts it pings the DDNS. In this case, we will use this URL as an example:
http://dynupdate.no-ip.com/nic/updateSee how no-ip.com 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 topipcam.org, that gets pinged when the camera has it defined as the DDNS, when the camera starts up.
http://www.topipcam.org/upgengxin.aspSee 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:
http://www.no-ip.com/integrate/http://www.no-ip.com/integrate/request/http://www.no-ip.com/integrate/response/Don
Menu
Account
Topic: NCB541W firmware and webui (Read 31868 times)