Amcrest Smart Home "Server" down?

[GaryOkie]

Got the SmartHome app and AD110 back online @pcabral ! No Factory Reset required.

Code: Select all

iptables -t nat -A PREROUTING -p tcp --dport 15301 -j DNAT --to-destination 34.199.92.115:15301

iptables -t nat -A POSTROUTING -j MASQUERADE

After ssh to the ASUSWRT/Merlin router, just entered these 2 iptable commands. Then needed to simply restart the smarthome app, and it connects.

Note that this command is rerouting any outbound TCP traffic on port 15301 so it doesn't care what the currently configured AD110 outbound DMS IP is, good or bad.

Now, ideally I would have liked to have specified the dms.zencamcloud.com hostname instead of the one of the IP's it now resolves to, but apparently that is not a good practice. Good enough for now. Looks to me that Amcrest will have to release a new firmware to fix this ridiculous issue.

[Revo2Maxx]

Was talking with R&D today and passed them 3 of my backups so they could see the IP I was on after the last outage then I did another backup before I reset the doorbell passed that one so he could see 8 days ago after a Reset it ws working, then today it wasn't before on same IP that it set last week. Then after reset today different IP and it is working again...

Interesting that your 34. address is different then the one I am on that starts at 50 and ends with 142 where last weeks IP ended in 209.. So also oddly I see there was 5319 after last weeks reset, Then 10 more lines when not working today to after the reset today there was more then 30 extra lines over that.

[GaryOkie]

As I had mentioned before, just do an nslookup dms.zencamcloud.com
It resolves to 2 IP's, and I arbitrarily chose 34.100.92.115. The other is 50.19.133.142. They both work.

This is how DNS round robin and basic load balancing is done when you connect to the fricking HOSTNAME, not a static IP which clearly hasn't been very static at all. Amazon is switching servers on and off and moving things around which is fairly normal practice in a big, er- huge datacenter.

Now, I don't pretend to know the details of how all of this is architected and I could certainly be off-base in some of my assertions. But I honestly don't think so after all these tests. If the iptables commands helps someone to avoid a factory reset - great.

EDIT: earlier I stated that it would have been preferable to set the destination to the dms hostname, not the IP but it was "not a best practice". To clarify, that statement was only in the context of using the iptables command as a temporary workaround. There is a security concern masquerading a redirected IP to a hostname which is why I didn't.

[pcabral]

@GaryOkie you are the man!!!!! Amcrest should give you free camera for your efforts or better yet some cash.... tax free of course....

[amcrest168]

shoot i won't be able to test because i have already done the hard reset. my doorbell is connected to a dd-wrt router that is configured as a client bridge. main router is on openwrt and it's a simply dns forwarding. hmm.. what if amazon changes servers again? have to do another nslookup for the ip addresses so i can modify dnsmasq?

[pcabral]

A mistake like this clearly shows the inexperienced software engineers developing these products, this should have been caught in a code review. Hardcoded IP addresses is a big No-No when developing applications that rely on internet network communications!!!

[amcrest168]

hi @GaryOkie, since you have not done a hard reset, can you disconnect from your home network and start the smart home app using just the data plan to test if the domain name can be resolved without the router assisted dns forwarding? good job finding the outage.

[GaryOkie]

what if amazon changes servers again? have to do another nslookup for the ip addresses

@amcrest168 Yes. Quite a bit easier than a factory reset + wifi setup tango, no?

can you disconnect from your home network and start the smart home app using just the data plan to test

Yep, tested that too. Works fine for remote access as well!

[srags]

@Revo2Maxx - I purchased direct from Amcrest two new AD110 and arrived unopened in shrink-wrap. I installed the first in Florida on May 30th and worked great until June 12th. The second I installed in Ohio on June 15th and is continuing to work correctly. Both are running the latest firmware.

I am wondering if I could use the http API to change the DMSServerIP to the IP that is working for my OH device?

Has anyone tested the http API restore or is there a function that can upload the config from the config.backup file?

That is why I was asking if we could use the http API command to change the DMSServerIP. I found the command but not authorized.

http://<AD110 IP>/cgi-bin/configManager.cgi?action=setConfig&name=VSP_PaaS.DMSServerIP="<working IP>"

[srags]

I have not factory reset either of my AD110s as I was waiting on Amcrest to fix this craziness...

And I just happen to run DD-WRT in both locations so I ended up using the following in OH

iptables -t nat -I PREROUTING -d 3.220.2.106 -j DNAT --to 50.19.133.142

and the following in FL to fix both AD110s.

iptables -t nat -I PREROUTING -d 52.0.147.128 -j DNAT --to 50.19.133.142

I am back online in both locations!! AWS changes public IPs all the time. Did not think about fixing the issue with router. Thanks for all of the good posts!!